From tls-bounces@lists.ietf.org Mon Jan 01 06:08:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1L0s-00054L-Ew; Mon, 01 Jan 2007 06:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1L0r-00054B-Lz for tls@ietf.org; Mon, 01 Jan 2007 06:07:29 -0500 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1L0i-0003mk-5y for tls@ietf.org; Mon, 01 Jan 2007 06:07:29 -0500 Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id l01B7Ebk015021 for ; Mon, 1 Jan 2007 11:07:14 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=wHf1jferMc7PP3fEB5lePamj5lmOf+mwi2HPtJbwu439Iu/JQ07AWP3EtvQ6SEl2C k8njizw9rCX5lqr0yx+Fg== Received: from wx-out-0506.google.com (wxdi27.prod.google.com [10.70.135.27]) by spaceape7.eur.corp.google.com with ESMTP id l01B7Bsd001834 for ; Mon, 1 Jan 2007 11:07:12 GMT Received: by wx-out-0506.google.com with SMTP id i27so6038253wxd for ; Mon, 01 Jan 2007 03:07:11 -0800 (PST) Received: by 10.90.52.2 with SMTP id z2mr13606228agz.1167649631710; Mon, 01 Jan 2007 03:07:11 -0800 (PST) Received: by 10.90.115.20 with HTTP; Mon, 1 Jan 2007 03:07:11 -0800 (PST) Message-ID: <1b587cab0701010307r32b56732nf85f545848a449a8@mail.gmail.com> Date: Mon, 1 Jan 2007 11:07:11 +0000 From: "Ben Laurie" To: "Nelson B Bolyard" Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY? In-Reply-To: <45984414.2090209@bolyard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44D32FC2.2080606@bolyard.com> <45984414.2090209@bolyard.com> X-Spam-Score: -4.3 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 12/31/06, Nelson B Bolyard wrote: > Last August, I wrote to this list about the lack of "MUST" in the RFCs and > drafts concerning the use of error and warning alerts. That message is > quoted below. I only got one reply, from Peter Gutmann. > > I really want to see this situation get fixed in TLS 1.2. What can I do > to make that happen? Do I need to submit a draft with the suggested changes? > Erik, if I send you a set of suggested changes as edits to the current 1.2 > draft, will you incorporate them? If you're going to make errors MUSTs you need to do so carefully, since information leakage through alerts has been the basis of several attacks on SSL/TLS. > OBTW, the "newer implementation" that nevre sends error alerts has been > released since I wrote that first message. Can you guess what it is? > > Nelson B Bolyard wrote: > > The existing TLS RFCs and IDs don't say that an implementation MUST send > > any error alerts. > > > > There's lots of "will", "should", "may", but not nearly enough "MUST" > > (IMO) regarding error alerts (whether fatal or not). > > > > > > Consequently, one of the newer implementations (which I won't name here), > > one with which I've been doing interoperability testing, simply NEVER sends > > error alerts. When any problem occurs, it silently closes the connection > > without offering any clues to the peer about why it has done so. The > > developer's explanation to me for the implementation's behavior was simple: > > the RFCs do not require that error alerts be sent. Sending error alerts is > > simply not a MUST. Doing so is implicitly a MAY, at most. > > > > I think this is going to be a nightmare for trouble shooting. When a peer > > system drops a TLS connection, we're going to have to rely on the ability > > of the user or administrator who runs that peer to determine why it did so, > > rather than relying on alerts. > > > > So, I put the question to the TLS WG: Is there consensus that the RFC > > language should be strengthened in the next version (e.g. rfc4346-bis) > > to say that the error alerts MUST be sent, and when? > > > > > > A survey of error alert discussion in the first 40-some pages of the draft. > > > > Regarding close notify alerts, the existing RFC and drafts say that "each > > party is required to" (why not MUST?) send a close_notify alert if no error > > condition has occurred and that upon receiving a close-notify alert, the > > peer MUST send one in respnse. So, close_notify alerts will get sent, > > but not error alerts. > > > > The latest draft says that when an error alert is sent or received, the > > session MUST be invalidated, but doesn't require that it be sent. > > > > The draft says: > > "When an error is detected, the detecting party sends a > > message to the other party." > > I think that should be MUST SEND, but as written it's not a MUST. > > > > There are some "SHOULD"s in the current draft rfc4346-bis: > > "The receiver MUST check this padding and SHOULD use the > > bad_record_mac alert to indicate padding errors." > > > > I think this was intended to be understood as "MUST check, MUST send an > > alert to indicate errors, and SHOULD use bad_record_mac alert when > > appropriate". But as written, it clearly makes sending any alert at all > > at most a SHOULD for bad macs. > > > > no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a > > MUST. certificate_unobtainable is a MAY. > > > > The text for client_hello says > > "The server will select a cipher suite or, if no acceptable choices are > > presented, return a handshake failure alert and close the connection." > > No MUST in there. > > > > The alerts on page 30 MUST NOT be sent except when the client used a > > hello extension. But there is no time when they MUST be used. > > > > In the current draft, I did find a few MUSTs. > > > > Page 37 has an inferred "will": > > The server will select a cipher suite or, if no acceptable choices are > > presented, return a handshake failure alert and close the connection. > > > > page 39 has a MUST: > > "... if not then it MUST send a fatal "decode_error" alert." > > > > section 7.4.1.3 says: "it will respond with a handshake failure alert." > > no MUST there. > > > > I found two MUSTS in 7.4.1.4.2 on page 44. Also a SHALL (isn't that > > supposed to be a MUST?) > > > > I'll stop there without reviewing every weak description of an error alert. > > Let's please have more MUSTs. > > > > > -- > Nelson B > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > 00000000011111111112222222222333333333344444444445555555555666666666677777777778 > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 01 08:58:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NfG-00013f-Qn; Mon, 01 Jan 2007 08:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NfF-00010R-66 for tls@ietf.org; Mon, 01 Jan 2007 08:57:21 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1NfE-0000q4-RK for tls@ietf.org; Mon, 01 Jan 2007 08:57:21 -0500 Received: by wx-out-0506.google.com with SMTP id h27so5669492wxd for ; Mon, 01 Jan 2007 05:57:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QJj8s42u0fm962T14VGaRoZ0FF2o9+Un7gMcaM3A1WbLwPWs98LM8w0r1+R95SjijPqZ7cuYKWyynn8mrmTHtemFQNzjdFMhOsGEGr1wqNE0od4SgBfnsoLxAPN+2KJKFxCkTn5cryXmNB9qqkgUNS72I//vM49Ihk/SeVkrWUI= Received: by 10.90.105.20 with SMTP id d20mr13663290agc.1167659840652; Mon, 01 Jan 2007 05:57:20 -0800 (PST) Received: by 10.90.56.2 with HTTP; Mon, 1 Jan 2007 05:57:20 -0800 (PST) Message-ID: <6b9359640701010557n37258268p7a5d6cbe087de98e@mail.gmail.com> Date: Mon, 1 Jan 2007 06:57:20 -0700 From: "Kyle Hamilton" To: "Ben Laurie" Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY? In-Reply-To: <1b587cab0701010307r32b56732nf85f545848a449a8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44D32FC2.2080606@bolyard.com> <45984414.2090209@bolyard.com> <1b587cab0701010307r32b56732nf85f545848a449a8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I think that probably the only "MUST" that should be in place is "if there is an error, a fatal error MUST be sent". I'd also go so far as to suggest that "protocol_error" be the generic one that must be sent if the implementation wishes not to leak any information at all. (the remote is an untrusted entity in the grand scheme of things... I wouldn't listen if it said I was speaking improperly anyway.) -Kyle H On 1/1/07, Ben Laurie wrote: > On 12/31/06, Nelson B Bolyard wrote: > > Last August, I wrote to this list about the lack of "MUST" in the RFCs and > > drafts concerning the use of error and warning alerts. That message is > > quoted below. I only got one reply, from Peter Gutmann. > > > > I really want to see this situation get fixed in TLS 1.2. What can I do > > to make that happen? Do I need to submit a draft with the suggested changes? > > Erik, if I send you a set of suggested changes as edits to the current 1.2 > > draft, will you incorporate them? > > If you're going to make errors MUSTs you need to do so carefully, > since information leakage through alerts has been the basis of several > attacks on SSL/TLS. > > > OBTW, the "newer implementation" that nevre sends error alerts has been > > released since I wrote that first message. Can you guess what it is? > > > > Nelson B Bolyard wrote: > > > The existing TLS RFCs and IDs don't say that an implementation MUST send > > > any error alerts. > > > > > > There's lots of "will", "should", "may", but not nearly enough "MUST" > > > (IMO) regarding error alerts (whether fatal or not). > > > > > > > > > Consequently, one of the newer implementations (which I won't name here), > > > one with which I've been doing interoperability testing, simply NEVER sends > > > error alerts. When any problem occurs, it silently closes the connection > > > without offering any clues to the peer about why it has done so. The > > > developer's explanation to me for the implementation's behavior was simple: > > > the RFCs do not require that error alerts be sent. Sending error alerts is > > > simply not a MUST. Doing so is implicitly a MAY, at most. > > > > > > I think this is going to be a nightmare for trouble shooting. When a peer > > > system drops a TLS connection, we're going to have to rely on the ability > > > of the user or administrator who runs that peer to determine why it did so, > > > rather than relying on alerts. > > > > > > So, I put the question to the TLS WG: Is there consensus that the RFC > > > language should be strengthened in the next version (e.g. rfc4346-bis) > > > to say that the error alerts MUST be sent, and when? > > > > > > > > > A survey of error alert discussion in the first 40-some pages of the draft. > > > > > > Regarding close notify alerts, the existing RFC and drafts say that "each > > > party is required to" (why not MUST?) send a close_notify alert if no error > > > condition has occurred and that upon receiving a close-notify alert, the > > > peer MUST send one in respnse. So, close_notify alerts will get sent, > > > but not error alerts. > > > > > > The latest draft says that when an error alert is sent or received, the > > > session MUST be invalidated, but doesn't require that it be sent. > > > > > > The draft says: > > > "When an error is detected, the detecting party sends a > > > message to the other party." > > > I think that should be MUST SEND, but as written it's not a MUST. > > > > > > There are some "SHOULD"s in the current draft rfc4346-bis: > > > "The receiver MUST check this padding and SHOULD use the > > > bad_record_mac alert to indicate padding errors." > > > > > > I think this was intended to be understood as "MUST check, MUST send an > > > alert to indicate errors, and SHOULD use bad_record_mac alert when > > > appropriate". But as written, it clearly makes sending any alert at all > > > at most a SHOULD for bad macs. > > > > > > no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a > > > MUST. certificate_unobtainable is a MAY. > > > > > > The text for client_hello says > > > "The server will select a cipher suite or, if no acceptable choices are > > > presented, return a handshake failure alert and close the connection." > > > No MUST in there. > > > > > > The alerts on page 30 MUST NOT be sent except when the client used a > > > hello extension. But there is no time when they MUST be used. > > > > > > In the current draft, I did find a few MUSTs. > > > > > > Page 37 has an inferred "will": > > > The server will select a cipher suite or, if no acceptable choices are > > > presented, return a handshake failure alert and close the connection. > > > > > > page 39 has a MUST: > > > "... if not then it MUST send a fatal "decode_error" alert." > > > > > > section 7.4.1.3 says: "it will respond with a handshake failure alert." > > > no MUST there. > > > > > > I found two MUSTS in 7.4.1.4.2 on page 44. Also a SHALL (isn't that > > > supposed to be a MUST?) > > > > > > I'll stop there without reviewing every weak description of an error alert. > > > Let's please have more MUSTs. > > > > > > > > > -- > > Nelson B > > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > > 00000000011111111112222222222333333333344444444445555555555666666666677777777778 > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > -- -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 01 09:40:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1OK9-00020T-BL; Mon, 01 Jan 2007 09:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1OK7-00020O-MD for tls@ietf.org; Mon, 01 Jan 2007 09:39:35 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1OK6-0006cJ-7G for tls@ietf.org; Mon, 01 Jan 2007 09:39:35 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l01Ec2IV029888; Mon, 1 Jan 2007 16:38:05 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 16:39:29 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 16:39:28 +0200 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 Subject: RE: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Date: Mon, 1 Jan 2007 16:39:25 +0200 Message-ID: In-Reply-To: <878xguzzv0.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Thread-Index: Acco3VQDhIRr62sgTQCQ3Q5SfumzHQE1NlGQ From: To: , X-OriginalArrivalTime: 01 Jan 2007 14:39:29.0081 (UTC) FILETIME=[A482C290:01C72DB2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070101163805-6E77FBB0-3187171F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > The document seems fine, but the intended status bothers me. Changing > the cipher suite numbers because the document now targets experimental > status will disrupt deployed implementations and harms adoption of the > protocol. Also, for this particular protocol, I believe its already > wide deployment suggests that PS is the appropriate choice. Note that all deployed implementation will be disrupted anyway, since=20 they use extension number 6, which has been already allocated for=20 RFC 4681. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 02 05:59:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hKz-0003gF-Uc; Tue, 02 Jan 2007 05:57:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hKz-0003fN-Dk for tls@ietf.org; Tue, 02 Jan 2007 05:57:45 -0500 Received: from webmail.ntru.com ([64.115.150.147] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hKx-0006y1-Ue for tls@ietf.org; Tue, 02 Jan 2007 05:57:45 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY? Date: Tue, 2 Jan 2007 05:54:00 -0500 Message-ID: <9DC3EBEFB87A97498A7D25F130DE27E4054253@ohthree.jjj-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] sending error alerts: MUST? SHOULD? MAY? Thread-Index: AcctMTeGpoxumXNNQkiXGDPkpgkGrQBKxeHB References: <44D32FC2.2080606@bolyard.com> <45984414.2090209@bolyard.com> From: "Whyte, William" To: "Nelson B Bolyard" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1470666341==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1470666341== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72E5C.D24554A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72E5C.D24554A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When I open this mail, or any of the replies to it, in Outlook: * Outlook goes up to taking up 95% of my CPU time * Outlook's memory requirements go up from 50(ish) MB to 190(ish) * Outlook, unsurprisingly, becomes unresponsive and has to be shut down from the Task Manager. =20 Is anyone else experiencing this? =20 William ________________________________ From: Nelson B Bolyard [mailto:nelson@bolyard.com] Sent: Sun 12/31/2006 6:13 PM To: tls@ietf.org Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY? Last August, I wrote to this list about the lack of "MUST" in the RFCs = and drafts concerning the use of error and warning alerts. That message is quoted below. I only got one reply, from Peter Gutmann. I really want to see this situation get fixed in TLS 1.2. What can I do to make that happen? Do I need to submit a draft with the suggested = changes? Erik, if I send you a set of suggested changes as edits to the current = 1.2 draft, will you incorporate them? OBTW, the "newer implementation" that nevre sends error alerts has been released since I wrote that first message. Can you guess what it is? Nelson B Bolyard wrote: > The existing TLS RFCs and IDs don't say that an implementation MUST = send > any error alerts. > > There's lots of "will", "should", "may", but not nearly enough "MUST" > (IMO) regarding error alerts (whether fatal or not). > > > Consequently, one of the newer implementations (which I won't name = here), > one with which I've been doing interoperability testing, simply NEVER = sends > error alerts. When any problem occurs, it silently closes the = connection > without offering any clues to the peer about why it has done so. The > developer's explanation to me for the implementation's behavior was = simple: > the RFCs do not require that error alerts be sent. Sending error = alerts is > simply not a MUST. Doing so is implicitly a MAY, at most. > > I think this is going to be a nightmare for trouble shooting. When a = peer > system drops a TLS connection, we're going to have to rely on the = ability > of the user or administrator who runs that peer to determine why it = did so, > rather than relying on alerts. > > So, I put the question to the TLS WG: Is there consensus that the RFC > language should be strengthened in the next version (e.g. rfc4346-bis) > to say that the error alerts MUST be sent, and when? > > > A survey of error alert discussion in the first 40-some pages of the = draft. > > Regarding close notify alerts, the existing RFC and drafts say that = "each > party is required to" (why not MUST?) send a close_notify alert if no = error > condition has occurred and that upon receiving a close-notify alert, = the > peer MUST send one in respnse. So, close_notify alerts will get sent, > but not error alerts. > > The latest draft says that when an error alert is sent or received, = the > session MUST be invalidated, but doesn't require that it be sent. > > The draft says: > "When an error is detected, the detecting party sends a > message to the other party." > I think that should be MUST SEND, but as written it's not a MUST. > > There are some "SHOULD"s in the current draft rfc4346-bis: > "The receiver MUST check this padding and SHOULD use the > bad_record_mac alert to indicate padding errors." > > I think this was intended to be understood as "MUST check, MUST send = an > alert to indicate errors, and SHOULD use bad_record_mac alert when > appropriate". But as written, it clearly makes sending any alert at = all > at most a SHOULD for bad macs. > > no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor = a > MUST. certificate_unobtainable is a MAY. > > The text for client_hello says > "The server will select a cipher suite or, if no acceptable choices = are > presented, return a handshake failure alert and close the = connection." > No MUST in there. > > The alerts on page 30 MUST NOT be sent except when the client used a > hello extension. But there is no time when they MUST be used. > > In the current draft, I did find a few MUSTs. > > Page 37 has an inferred "will": > The server will select a cipher suite or, if no acceptable choices = are > presented, return a handshake failure alert and close the = connection. > > page 39 has a MUST: > "... if not then it MUST send a fatal "decode_error" alert." > > section 7.4.1.3 says: "it will respond with a handshake failure = alert." > no MUST there. > > I found two MUSTS in 7.4.1.4.2 on page 44. Also a SHALL (isn't that > supposed to be a MUST?) > > I'll stop there without reviewing every weak description of an error = alert. > Let's please have more MUSTs. > -- Nelson B 1234567890123456789012345678901234567890123456789012345678901234567890123= 4567890 0000000001111111111222222222233333333334444444444555555555566666666667777= 7777778 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls ------_=_NextPart_001_01C72E5C.D24554A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [TLS] sending error alerts: MUST? SHOULD? MAY?=0A= =0A= =0A=
=0A=
When I open = this mail, or any =0A= of the replies to it, in Outlook:
=0A=
* Outlook goes up to taking = up 95% of my =0A= CPU time
=0A=
* Outlook's memory = requirements go up from =0A= 50(ish) MB to 190(ish)
=0A=
* Outlook, unsurprisingly, = becomes =0A= unresponsive and has to be shut
=0A=
  down from the Task =0A= Manager.
=0A=
 
=0A=
Is anyone else experiencing =0A= this?
=0A=
 
=0A=
William
=0A=

=0A=
=0A= From: Nelson B Bolyard =0A= [mailto:nelson@bolyard.com]
Sent: Sun 12/31/2006 6:13 = PM
To: =0A= tls@ietf.org
Subject: Re: [TLS] sending error alerts: MUST? = SHOULD? =0A= MAY?

=0A=
=0A=

Last August, I wrote to this list about the lack of = "MUST" in =0A= the RFCs and
drafts concerning the use of error and warning = alerts.  =0A= That message is
quoted below.  I only got one reply, from Peter =0A= Gutmann.

I really want to see this situation get fixed in TLS = 1.2.  =0A= What can I do
to make that happen?  Do I need to submit a draft = with the =0A= suggested changes?
Erik, if I send you a set of suggested changes as = edits to =0A= the current 1.2
draft, will you incorporate them?

OBTW, the = "newer =0A= implementation" that nevre sends error alerts has been
released since = I wrote =0A= that first message.  Can you guess what it is?

Nelson B = Bolyard =0A= wrote:
> The existing TLS RFCs and IDs don't say that an = implementation =0A= MUST send
> any error alerts.
>
> There's lots of = "will", =0A= "should", "may", but not nearly enough "MUST"
> (IMO) regarding = error =0A= alerts (whether fatal or not).
>
>
> Consequently, one = of the =0A= newer implementations (which I won't name here),
> one with which = I've =0A= been doing interoperability testing, simply NEVER sends
> error =0A= alerts.  When any problem occurs, it silently closes the = connection
> =0A= without offering any clues to the peer about why it has done so.  =0A= The
> developer's explanation to me for the implementation's = behavior was =0A= simple:
> the RFCs do not require that error alerts be sent.  = Sending =0A= error alerts is
> simply not a MUST.  Doing so is implicitly = a MAY, =0A= at most.
>
> I think this is going to be a nightmare for = trouble =0A= shooting.  When a peer
> system drops a TLS connection, we're = going =0A= to have to rely on the ability
> of the user or administrator who = runs =0A= that peer to determine why it did so,
> rather than relying on =0A= alerts.
>
> So, I put the question to the TLS WG:  Is = there =0A= consensus that the RFC
> language should be strengthened in the = next =0A= version (e.g. rfc4346-bis)
> to say that the error alerts MUST be = sent, =0A= and when?
>
>
> A survey of error alert discussion in = the =0A= first 40-some pages of the draft.
>
> Regarding close notify = alerts, =0A= the existing RFC and drafts say that "each
> party is required to" = (why =0A= not MUST?) send a close_notify alert if no error
> condition has = occurred =0A= and that upon receiving a close-notify alert, the
> peer MUST send = one in =0A= respnse.  So, close_notify alerts will get sent,
> but not = error =0A= alerts.
>
> The latest draft says that when an error alert = is sent =0A= or received, the
> session MUST be invalidated, but doesn't = require that =0A= it be sent.
>
> The draft says:
>    = "When an =0A= error is detected, the detecting party sends = a
>     =0A= message to the other party."
> I think that should be MUST SEND, = but as =0A= written it's not a MUST.
>
> There are some "SHOULD"s in the = current =0A= draft rfc4346-bis:
>    "The receiver MUST check = this =0A= padding and SHOULD use the
>     = bad_record_mac alert =0A= to indicate padding errors."
>
> I think this was intended = to be =0A= understood as "MUST check, MUST send an
> alert to indicate = errors, and =0A= SHOULD use bad_record_mac alert when
> appropriate".  But as = written, =0A= it clearly makes sending any alert at all
> at most a SHOULD for = bad =0A= macs.
>
> no_renegotiation is a should, (and a MUST NOT) but = never a =0A= SHOULD nor a
> MUST.  certificate_unobtainable is a =0A= MAY.
>
> The text for client_hello = says
>    =0A= "The server will select a cipher suite or, if no acceptable choices =0A= are
>     presented, return a handshake = failure alert =0A= and close the connection."
> No MUST in there.
>
> The = alerts =0A= on page 30 MUST NOT be sent except when the client used a
> hello =0A= extension.  But there is no time when they MUST be = used.
>
> In =0A= the current draft, I did find a few MUSTs.
>
> Page 37 has = an =0A= inferred "will":
>    The server will select a = cipher suite =0A= or, if no acceptable choices are
>    presented, = return a =0A= handshake failure alert and close the connection.
>
> page = 39 has a =0A= MUST:
>    "... if not then it MUST send a fatal =0A= "decode_error" alert."
>
> section 7.4.1.3 says: "it will = respond =0A= with a handshake failure alert."
>     no MUST =0A= there.
>
> I found two MUSTS in 7.4.1.4.2 on page 44.  = Also a =0A= SHALL (isn't that
> supposed to be a MUST?)
>
> I'll = stop =0A= there without reviewing every weak description of an error = alert.
> Let's =0A= please have more MUSTs.
>


--
Nelson =0A= B
12345678901234567890123456789012345678901234567890123456789012345678= 901234567890
000000000111111111122222222223333333333444444444455555555= 55666666666677777777778

__________________________________________= _____
TLS =0A= mailing list
TLS@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/tls

=0A= =0A= =0A= ------_=_NextPart_001_01C72E5C.D24554A0-- --===============1470666341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1470666341==-- From tls-bounces@lists.ietf.org Tue Jan 02 06:27:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hnv-0004pd-US; Tue, 02 Jan 2007 06:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hnu-0004n1-1E for tls@ietf.org; Tue, 02 Jan 2007 06:27:38 -0500 Received: from webmail.ntru.com ([64.115.150.147] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hnr-0006CR-9y for tls@ietf.org; Tue, 02 Jan 2007 06:27:38 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY? Date: Tue, 2 Jan 2007 06:25:16 -0500 Message-ID: <9DC3EBEFB87A97498A7D25F130DE27E4054255@ohthree.jjj-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] sending error alerts: MUST? SHOULD? MAY? Thread-Index: AcctMTeGpoxumXNNQkiXGDPkpgkGrQBKxeHBAAEXq88= References: <44D32FC2.2080606@bolyard.com> <45984414.2090209@bolyard.com> <9DC3EBEFB87A97498A7D25F130DE27E4054253@ohthree.jjj-i.com> From: "Whyte, William" To: "Whyte, William" , "Nelson B Bolyard" , X-Spam-Score: 0.1 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0849266459==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0849266459== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72E60.FF0D13C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72E60.FF0D13C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It turns out to be something to do with the Skype toolbar trying to = convert Nelson's =20 1234567890123456789012345678901234567890123456789012345678901234567890123= 4567890 0000000001111111111222222222233333333334444444444555555555566666666667777= 7777778 into a phone number. (I got similar behavior when I looked at Nelson's=20 mail on the web archives = http://www1.ietf.org/mail-archive/web/tls/current/msg01286.html in Firefox, where I also have the Skype toolbar installed). Nice one, = Skype! =20 William ________________________________ From: Whyte, William [mailto:WWhyte@ntru.com] Sent: Tue 1/2/2007 5:54 AM To: Nelson B Bolyard; tls@ietf.org Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY? When I open this mail, or any of the replies to it, in Outlook: * Outlook goes up to taking up 95% of my CPU time * Outlook's memory requirements go up from 50(ish) MB to 190(ish) * Outlook, unsurprisingly, becomes unresponsive and has to be shut down from the Task Manager. =20 Is anyone else experiencing this? =20 William ________________________________ From: Nelson B Bolyard [mailto:nelson@bolyard.com] Sent: Sun 12/31/2006 6:13 PM To: tls@ietf.org Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY? Last August, I wrote to this list about the lack of "MUST" in the RFCs = and drafts concerning the use of error and warning alerts. That message is quoted below. I only got one reply, from Peter Gutmann. I really want to see this situation get fixed in TLS 1.2. What can I do to make that happen? Do I need to submit a draft with the suggested = changes? Erik, if I send you a set of suggested changes as edits to the current = 1.2 draft, will you incorporate them? OBTW, the "newer implementation" that nevre sends error alerts has been released since I wrote that first message. Can you guess what it is? Nelson B Bolyard wrote: > The existing TLS RFCs and IDs don't say that an implementation MUST = send > any error alerts. > > There's lots of "will", "should", "may", but not nearly enough "MUST" > (IMO) regarding error alerts (whether fatal or not). > > > Consequently, one of the newer implementations (which I won't name = here), > one with which I've been doing interoperability testing, simply NEVER = sends > error alerts. When any problem occurs, it silently closes the = connection > without offering any clues to the peer about why it has done so. The > developer's explanation to me for the implementation's behavior was = simple: > the RFCs do not require that error alerts be sent. Sending error = alerts is > simply not a MUST. Doing so is implicitly a MAY, at most. > > I think this is going to be a nightmare for trouble shooting. When a = peer > system drops a TLS connection, we're going to have to rely on the = ability > of the user or administrator who runs that peer to determine why it = did so, > rather than relying on alerts. > > So, I put the question to the TLS WG: Is there consensus that the RFC > language should be strengthened in the next version (e.g. rfc4346-bis) > to say that the error alerts MUST be sent, and when? > > > A survey of error alert discussion in the first 40-some pages of the = draft. > > Regarding close notify alerts, the existing RFC and drafts say that = "each > party is required to" (why not MUST?) send a close_notify alert if no = error > condition has occurred and that upon receiving a close-notify alert, = the > peer MUST send one in respnse. So, close_notify alerts will get sent, > but not error alerts. > > The latest draft says that when an error alert is sent or received, = the > session MUST be invalidated, but doesn't require that it be sent. > > The draft says: > "When an error is detected, the detecting party sends a > message to the other party." > I think that should be MUST SEND, but as written it's not a MUST. > > There are some "SHOULD"s in the current draft rfc4346-bis: > "The receiver MUST check this padding and SHOULD use the > bad_record_mac alert to indicate padding errors." > > I think this was intended to be understood as "MUST check, MUST send = an > alert to indicate errors, and SHOULD use bad_record_mac alert when > appropriate". But as written, it clearly makes sending any alert at = all > at most a SHOULD for bad macs. > > no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor = a > MUST. certificate_unobtainable is a MAY. > > The text for client_hello says > "The server will select a cipher suite or, if no acceptable choices = are > presented, return a handshake failure alert and close the = connection." > No MUST in there. > > The alerts on page 30 MUST NOT be sent except when the client used a > hello extension. But there is no time when they MUST be used. > > In the current draft, I did find a few MUSTs. > > Page 37 has an inferred "will": > The server will select a cipher suite or, if no acceptable choices = are > presented, return a handshake failure alert and close the = connection. > > page 39 has a MUST: > "... if not then it MUST send a fatal "decode_error" alert." > > section 7.4.1.3 says: "it will respond with a handshake failure = alert." > no MUST there. > > I found two MUSTS in 7.4.1.4.2 on page 44. Also a SHALL (isn't that > supposed to be a MUST?) > > I'll stop there without reviewing every weak description of an error = alert. > Let's please have more MUSTs. > -- Nelson B 1234567890123456789012345678901234567890123456789012345678901234567890123= 4567890 0000000001111111111222222222233333333334444444444555555555566666666667777= 7777778 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls ------_=_NextPart_001_01C72E60.FF0D13C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= Re: [TLS] sending error alerts: MUST? SHOULD? MAY?=0A= =0A= =0A=
=0A=
It turns out = to be something =0A= to do with the Skype toolbar trying to convert
=0A=
Nelson's
=0A=
 
=0A=
1234567890123456789012345678901234567890123456789012345678901234= 5678901234567890
00000000011111111112222222222333333333344444444445555= 555555666666666677777777778
=0A=
into a phone number. (I got similar behavior when I = looked at =0A= Nelson's
=0A= =0A=
in Firefox, where I also have the Skype toolbar = installed). Nice =0A= one, Skype!
=0A=
 
=0A=
William
=0A=

=0A=
=0A= From: Whyte, William =0A= [mailto:WWhyte@ntru.com]
Sent: Tue 1/2/2007 5:54 = AM
To: =0A= Nelson B Bolyard; tls@ietf.org
Subject: RE: [TLS] sending = error =0A= alerts: MUST? SHOULD? MAY?

=0A=
=0A=
=0A=
When I open = this mail, or any =0A= of the replies to it, in Outlook:
=0A=
* Outlook goes up to taking = up 95% of my =0A= CPU time
=0A=
* Outlook's memory = requirements go up from =0A= 50(ish) MB to 190(ish)
=0A=
* Outlook, unsurprisingly, = becomes =0A= unresponsive and has to be shut
=0A=
  down from the Task =0A= Manager.
=0A=
 
=0A=
Is anyone else experiencing =0A= this?
=0A=
 
=0A=
William
=0A=

=0A=
=0A= From: Nelson B Bolyard =0A= [mailto:nelson@bolyard.com]
Sent: Sun 12/31/2006 6:13 = PM
To: =0A= tls@ietf.org
Subject: Re: [TLS] sending error alerts: MUST? = SHOULD? =0A= MAY?

=0A=
=0A=

Last August, I wrote to this list about the lack of = "MUST" in =0A= the RFCs and
drafts concerning the use of error and warning = alerts.  =0A= That message is
quoted below.  I only got one reply, from Peter =0A= Gutmann.

I really want to see this situation get fixed in TLS = 1.2.  =0A= What can I do
to make that happen?  Do I need to submit a draft = with the =0A= suggested changes?
Erik, if I send you a set of suggested changes as = edits to =0A= the current 1.2
draft, will you incorporate them?

OBTW, the = "newer =0A= implementation" that nevre sends error alerts has been
released since = I wrote =0A= that first message.  Can you guess what it is?

Nelson B = Bolyard =0A= wrote:
> The existing TLS RFCs and IDs don't say that an = implementation =0A= MUST send
> any error alerts.
>
> There's lots of = "will", =0A= "should", "may", but not nearly enough "MUST"
> (IMO) regarding = error =0A= alerts (whether fatal or not).
>
>
> Consequently, one = of the =0A= newer implementations (which I won't name here),
> one with which = I've =0A= been doing interoperability testing, simply NEVER sends
> error =0A= alerts.  When any problem occurs, it silently closes the = connection
> =0A= without offering any clues to the peer about why it has done so.  =0A= The
> developer's explanation to me for the implementation's = behavior was =0A= simple:
> the RFCs do not require that error alerts be sent.  = Sending =0A= error alerts is
> simply not a MUST.  Doing so is implicitly = a MAY, =0A= at most.
>
> I think this is going to be a nightmare for = trouble =0A= shooting.  When a peer
> system drops a TLS connection, we're = going =0A= to have to rely on the ability
> of the user or administrator who = runs =0A= that peer to determine why it did so,
> rather than relying on =0A= alerts.
>
> So, I put the question to the TLS WG:  Is = there =0A= consensus that the RFC
> language should be strengthened in the = next =0A= version (e.g. rfc4346-bis)
> to say that the error alerts MUST be = sent, =0A= and when?
>
>
> A survey of error alert discussion in = the =0A= first 40-some pages of the draft.
>
> Regarding close notify = alerts, =0A= the existing RFC and drafts say that "each
> party is required to" = (why =0A= not MUST?) send a close_notify alert if no error
> condition has = occurred =0A= and that upon receiving a close-notify alert, the
> peer MUST send = one in =0A= respnse.  So, close_notify alerts will get sent,
> but not = error =0A= alerts.
>
> The latest draft says that when an error alert = is sent =0A= or received, the
> session MUST be invalidated, but doesn't = require that =0A= it be sent.
>
> The draft says:
>    = "When an =0A= error is detected, the detecting party sends = a
>     =0A= message to the other party."
> I think that should be MUST SEND, = but as =0A= written it's not a MUST.
>
> There are some "SHOULD"s in the = current =0A= draft rfc4346-bis:
>    "The receiver MUST check = this =0A= padding and SHOULD use the
>     = bad_record_mac alert =0A= to indicate padding errors."
>
> I think this was intended = to be =0A= understood as "MUST check, MUST send an
> alert to indicate = errors, and =0A= SHOULD use bad_record_mac alert when
> appropriate".  But as = written, =0A= it clearly makes sending any alert at all
> at most a SHOULD for = bad =0A= macs.
>
> no_renegotiation is a should, (and a MUST NOT) but = never a =0A= SHOULD nor a
> MUST.  certificate_unobtainable is a =0A= MAY.
>
> The text for client_hello = says
>    =0A= "The server will select a cipher suite or, if no acceptable choices =0A= are
>     presented, return a handshake = failure alert =0A= and close the connection."
> No MUST in there.
>
> The = alerts =0A= on page 30 MUST NOT be sent except when the client used a
> hello =0A= extension.  But there is no time when they MUST be = used.
>
> In =0A= the current draft, I did find a few MUSTs.
>
> Page 37 has = an =0A= inferred "will":
>    The server will select a = cipher suite =0A= or, if no acceptable choices are
>    presented, = return a =0A= handshake failure alert and close the connection.
>
> page = 39 has a =0A= MUST:
>    "... if not then it MUST send a fatal =0A= "decode_error" alert."
>
> section 7.4.1.3 says: "it will = respond =0A= with a handshake failure alert."
>     no MUST =0A= there.
>
> I found two MUSTS in 7.4.1.4.2 on page 44.  = Also a =0A= SHALL (isn't that
> supposed to be a MUST?)
>
> I'll = stop =0A= there without reviewing every weak description of an error = alert.
> Let's =0A= please have more MUSTs.
>


--
Nelson =0A= B
12345678901234567890123456789012345678901234567890123456789012345678= 901234567890
000000000111111111122222222223333333333444444444455555555= 55666666666677777777778

__________________________________________= _____
TLS =0A= mailing list
TLS@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/tls

=0A= =0A= =0A= ------_=_NextPart_001_01C72E60.FF0D13C0-- --===============0849266459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0849266459==-- From tls-bounces@lists.ietf.org Tue Jan 02 11:33:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mYM-0001ji-CI; Tue, 02 Jan 2007 11:31:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mYL-0001jd-5O for tls@ietf.org; Tue, 02 Jan 2007 11:31:53 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mYJ-0002Wt-Pn for tls@ietf.org; Tue, 02 Jan 2007 11:31:53 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA17759; Tue, 2 Jan 2007 17:31:45 +0100 (MEZ) From: Martin Rex Message-Id: <200701021631.RAA20033@uw1048.wdf.sap.corp> Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, To: home_pw@msn.com Date: Tue, 2 Jan 2007 17:31:45 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Dec 31, 6 11:58:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > Concerning 7.4.5. Certificate request > > "A list of the distinguished names of acceptable certificate > authorities. These distinguished names may specify a desired > distinguished name for a root CA or for a subordinate CA; > thus, this message can be used both to describe known roots > and a desired authorization space. If the > certificate_authorities list is empty then the client MAY > send any certificate of the appropriate > ClientCertificateType, unless there is some external > arrangement to the contrary." > > > So, what does this all really mean, > just staying within the traditional PKI world? This is *NOT* about PKI. It is about X.509 certificates and certificate chains. It means that the client should search his credentials and see whether there is a match between one of the CAs from that list of the Server and the issuer field of the certificate of the clients credentials (itself, or of (one) of its chain(s)). If there's at least one match, the client can use that credentials for client authentication, including the certification path up to at least the matching CA from the servers list. X.509 certs must be DER-encoded, and there MUST be a binary/opaque match of the CA name sent by the server with the issuer name in the clients (end-entity or path) certificate, therefore all the DNames in that list must be DER-encoded (or will likely not match issuer names - except for broken CAs issuing defective certs with non-DER encoded issuer names). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 12:34:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29zC-0003aW-My; Wed, 03 Jan 2007 12:33:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29zB-0003aO-Ip for tls@lists.ietf.org; Wed, 03 Jan 2007 12:33:09 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29z6-0005rW-UF for tls@lists.ietf.org; Wed, 03 Jan 2007 12:33:09 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 63C6D122 for ; Wed, 3 Jan 2007 18:33:01 +0100 (NFT) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 14916-03 for ; Wed, 3 Jan 2007 18:32:58 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C9E1914A for ; Wed, 3 Jan 2007 18:32:57 +0100 (NFT) Message-ID: <459BE8C8.1060307@uni-tuebingen.de> Date: Wed, 03 Jan 2007 18:32:56 +0100 From: Ali Fessi User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [TLS] Key exchange with DH_RSA X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi all, The TLS specification says (RFC4346 - Section 7.4.3. "Server Key Exchange Message") "It is not legal to send the server key exchange message for the following key exchange methods: RSA DH_DSS DH_RSA" But in case of *DH_RSA*, how can the DH exchange be completed if the client does not receive any DH value from the server in the "Server Key Exchange Message", nor does the certificate in the "Server Certificate" message include any helpful information to complete the DH exchange (since the public key of the certificate is an RSA public key)? In other words: how can a *non-ephemeral* DH be achieved, if the server's certificate key type is RSA? Thanks in advance! Ali -- Ali Fessi Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 12:41:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2A6X-0007Te-Sg; Wed, 03 Jan 2007 12:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2A6W-0007Qo-9v for tls@lists.ietf.org; Wed, 03 Jan 2007 12:40:44 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2A6V-0006nu-0Q for tls@lists.ietf.org; Wed, 03 Jan 2007 12:40:44 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 630221E8C2A; Wed, 3 Jan 2007 09:40:42 -0800 (PST) To: Ali Fessi Subject: Re: [TLS] Key exchange with DH_RSA References: <459BE8C8.1060307@uni-tuebingen.de> From: Eric Rescorla Date: Wed, 03 Jan 2007 09:40:42 -0800 In-Reply-To: <459BE8C8.1060307@uni-tuebingen.de> (Ali Fessi's message of "Wed, 03 Jan 2007 18:32:56 +0100") Message-ID: <86zm9057qd.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Ali Fessi writes: > Hi all, > > The TLS specification says (RFC4346 - Section 7.4.3. "Server Key > Exchange Message") > > "It is not legal to send the server key exchange message for the > following key exchange methods: > > RSA > DH_DSS > DH_RSA" > > But in case of *DH_RSA*, how can the DH exchange be completed if the > client does not receive any DH value from the server in the "Server > Key Exchange Message", nor does the certificate in the "Server > Certificate" message include any helpful information to complete the > DH exchange (since the public key of the certificate is an RSA public > key)? > > In other words: how can a *non-ephemeral* DH be achieved, if the > server's certificate key type is RSA? DH_RSA and DH_DSS mean "a static DH cert signed with RSA/DSS" -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 14:42:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bz5-0007nE-MX; Wed, 03 Jan 2007 14:41:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bz3-0007n9-KO for tls@ietf.org; Wed, 03 Jan 2007 14:41:09 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Bz1-0001QN-7G for tls@ietf.org; Wed, 03 Jan 2007 14:41:09 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 61F89821C; Wed, 3 Jan 2007 13:41:04 -0600 (CST) From: "Mark Brown" To: , "'EKR'" Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 3 Jan 2007 13:42:37 -0600 Message-ID: <002401c72f6f$5269f6e0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwGGteowAWbetZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Happy New Year, all. I'm responding to Eric's initial questions, and I will avoid topics not relevant to TLS and this group. Eric, I think you're right about the problems with the start1, start2, end1, end2 alerts. They could cause deadlocks, seem to require and multiply application-level interactions, and chew up alert space. I'd be open to abandoning them. Removing these from the drafts would require some other changes, perhaps removing any kind of reset over the application data sent & received hashes, etc. But removing these alerts would simplify several things, which seems good. Also, I think the alerts issue and some other unclear parts of the -00 and -01 drafts led to some misunderstandings about how TLS Evidence works. Let me get back to this in a later email. Most important, why should TLS WG do this? Overall, it would be advantageous to some users to use TLS's crypto to preserve a record of communications, that is, the bits and bytes that were actually sent and received. More specifically, Why should TLS be chosen as a good place in the 7 layer stack to create this record / evidence of what was actually sent/received? 1) Do it once at TLS, and get it right for lots of apps, don't reinvent the same idea in many standards / apps. The basic issue of creating a mirror-image / forgery-resistant record may be useful to most Internet app protocols. 2) The TLS layer is the better place to manage keypairs, put crypto algorithms (TLS vs. the O/S, not app layer, is an equally good question), verify PKCs within an Internet communications context, and assure crypto correctness vs. the app layer 3) The TLS handshake guards against replay attacks. Now that TLS Evidence and Supplemental Data exist it may contain other relevant and useful TLS Extensions in it, and you don't get access to this data at the app layer 4) It's better to provide a wide variety of crypto options (using TLS) than to use just one or two algorithms. TLS offers one of the best selections of cipher suites available. If evidence is implemented at the app layer, each app will face cost issues that promote their selection of "just the best crypto algorithm" leading to brittle reliance on that algorithm and incompatibilities between apps. Moreover, key agreement and key management is what TLS does very well and is hard to do well. Certainly a choice exists here: should we try to record what the app and the user "thinks" or "intends" or should we try to record what was, objectively, sent and received. TLS Evidence aims at the latter. Given this choice to focus, objectively, on the app data that was sent / received then the way that data looked just before it was encrypted (and HMAC'd) is a good place to "watch" the data. The TLS location is a good place to try to avoid "he said / she said" arguments -- the TLS HMAC ensures that what was sent was what was received, if anything was received at all. But, as I point out below, just storing the TLS packets including their HMAC isn't too durable against forgery attempts (on the basis of TLS crypto alone). More generally, why is -evidence useful? Here's my mission statement for TLS Evidence: There are times when parties would like to have a record where crypto was used so that the objective record of what was sent/received resists forgery. Here's an example to motivate why someone might want an un-forgeable record. Say you're buying tickets to a popular concert/movie/etc. online (i.e., limited inventory situation). In this case you (buyer) might care even more about getting a ticket than its price. So when you show up at the venue you want your electronic tickets / records of sale sustain a fair verification effort that they are not forgeries. You do not want the venue manager to say, "Sorry, we don't have records of this transaction..." Simply printing out records from a browser that bear a "https://" prefix in the URL (etc.) does not preclude forgery. Also, if either or both parties retain the full TLS session data, that doesn't preclude forgeries either (even in the case of TLS mutual authentication; more on this below). However, the design of TLS Evidence is that if one or both parties retain the full TLS session data then verification is quick and easy. A user should be able to download the TLS session data to his/her handheld/mobile computer and take that record instead of tickets, in the example above, and sustain a fair verification by the doorkeepers to the venue. (If the doorkeeper has lost the record, then the user can either use software that is accessible to the handheld and that passes muster, e.g. a well-known website, or the user may share the TLS session data for the doorkeeper to verify using the doorkeeper's software, e.g. email it.) Here, the crypto properties of the record make it so that anyone's copy is a good copy and is sufficient to stand up to scrutiny. The crypto properties make great records/evidence relatively cheap to create, and you don't need to keep the records on secure hardware or in a vault. Again, it's the crypto not the storage practices that make it a good record. It was suggested earlier that just storing the traffic keys is useful evidence in some cases. > >> Why not just store the traffic keys? I don't think this helps very much against claims of forgery. That's because the symmetric secrets derived from the TLS Pre-master Secret (including client MAC, server MAC, client write, server write, client IV, and server IV) are available to _both_ parties. Both parties may write data as if they were the other. So it is easy for both parties to change the record at any time after the fact. Either can attack the TLS record between the handshake and the first packet of application data. First cut the packet record between the last FINISHED message and the first application data record and throw away the old application data (or set it aside to use as a template). Now, take the handshake and splice onto it any application data you want -- making sure to use both TLS client's and server's MAC, write and IV secrets as proscribed by the specification. To add realism, the attacker has the old record of what was actually sent & received so the attacker can reuse any bits of that record to make the forgery look more realistic. My point here is that the cryptography used by SSL/TLS doesn't preclude forgeries made by client OR server, it only deters third parties from making forgeries. I will respond to your detailed comments in another email (this one is long enough). I will also supply an example of the TLS Evidence protocol for this "Sure you can verify my tickets" use case. -mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 15:50:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D3a-0003HJ-V5; Wed, 03 Jan 2007 15:49:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D3Z-0003GL-3h for tls@ietf.org; Wed, 03 Jan 2007 15:49:53 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2D3W-0004za-3f for tls@ietf.org; Wed, 03 Jan 2007 15:49:53 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1BE901E8C28; Wed, 3 Jan 2007 12:49:49 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <002401c72f6f$5269f6e0$6801a8c0@rps.local> From: Eric Rescorla Date: Wed, 03 Jan 2007 12:49:49 -0800 In-Reply-To: <002401c72f6f$5269f6e0$6801a8c0@rps.local> (Mark Brown's message of "Wed, 3 Jan 2007 13:42:37 -0600") Message-ID: <86y7oj4yz6.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: > I think you're right about the problems with the start1, start2, end1, end2 > alerts. They could cause deadlocks, seem to require and multiply > application-level interactions, and chew up alert space. I'd be open to > abandoning them. Removing these from the drafts would require some other > changes, perhaps removing any kind of reset over the application data sent & > received hashes, etc. But removing these alerts would simplify several > things, which seems good. This makes some problems worse but some better. To the extent to which one side's behavior is conditioned on the other's (E.g., I require a signature before taking an action) then having the signature only at the end causes problems. Plus, in Web contexts TLS connection closure behavior can be quite complicated due to persistent connections and bad TLS closure implementation. > Most important, why should TLS WG do this? Overall, it would be > advantageous to some users to use TLS's crypto to preserve a record of > communications, that is, the bits and bytes that were actually sent and > received. More specifically, Why should TLS be chosen as a good place in > the 7 layer stack to create this record / evidence of what was actually > sent/received? > > 1) Do it once at TLS, and get it right for lots of apps, don't reinvent the > same idea in many standards / apps. The basic issue of creating a > mirror-image / forgery-resistant record may be useful to most Internet app > protocols. But the problem is that doing it at the TLS layer entails not really getting it right for most apps, for the reasons that people have indicated so far--which is why signatures like this traditionally go in the application layer. > 2) The TLS layer is the better place to manage keypairs, put crypto > algorithms (TLS vs. the O/S, not app layer, is an equally good question), > verify PKCs within an Internet communications context, and assure crypto > correctness vs. the app layer I don't agree with this claim. The app needs to be cognizant of many of these properties. > 3) The TLS handshake guards against replay attacks. Now that TLS Evidence > and Supplemental Data exist it may contain other relevant and useful TLS > Extensions in it, and you don't get access to this data at the app layer > 4) It's better to provide a wide variety of crypto options (using TLS) than > to use just one or two algorithms. TLS offers one of the best selections of > cipher suites available. If evidence is implemented at the app layer, each > app will face cost issues that promote their selection of "just the best > crypto algorithm" leading to brittle reliance on that algorithm and > incompatibilities between apps. Moreover, key agreement and key management > is what TLS does very well and is hard to do well. But this isn't about key management or key agreement. It's about 3rd party proof, which is something that TLS does not at all. > It was suggested earlier that just storing the traffic keys is useful > evidence in some cases. That's not what I suggested. >> >> Why not just store the traffic keys? > > I don't think this helps very much against claims of forgery. That's > because the symmetric secrets derived from the TLS Pre-master Secret > (including client MAC, server MAC, client write, server write, client IV, > and server IV) are available to _both_ parties. Both parties may write data > as if they were the other. So it is easy for both parties to change the > record at any time after the fact. Either can attack the TLS record between > the handshake and the first packet of application data. First cut the > packet record between the last FINISHED message and the first application > data record and throw away the old application data (or set it aside to use > as a template). Now, take the handshake and splice onto it any application > data you want -- making sure to use both TLS client's and server's MAC, > write and IV secrets as proscribed by the specification. To add realism, > the attacker has the old record of what was actually sent & received so the > attacker can reuse any bits of that record to make the forgery look more > realistic. My point here is that the cryptography used by SSL/TLS doesn't > preclude forgeries made by client OR server, it only deters third parties > from making forgeries. Yes, I'm quite aware of this point, but it's not relevant to what I was saying, which is that it's not necessary to parse the handshake in order to recover the plaintext: you just store copies of the traffic keys and then you don't need to parse the handshake. > I will respond to your detailed comments in another email (this one is long > enough). I will also supply an example of the TLS Evidence protocol for > this "Sure you can verify my tickets" use case. Mark, nobody is doubting tha it's attractive to be able to provide third party evidence of what happened in a given transaction. That's why so much work has been put into digitally signing application layer traffic. The question at hand is where in the stack this functionality should go. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 17:36:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ei8-0002g0-KW; Wed, 03 Jan 2007 17:35:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ei6-0002fG-4b for tls@ietf.org; Wed, 03 Jan 2007 17:35:50 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Ei3-0001fe-Oa for tls@ietf.org; Wed, 03 Jan 2007 17:35:50 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id DDAE4841D; Wed, 3 Jan 2007 16:35:46 -0600 (CST) From: "Mark Brown" To: "'EKR'" , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 3 Jan 2007 16:37:19 -0600 Message-ID: <003301c72f87$ba822410$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <86y7oj4yz6.fsf@raman.networkresonance.com> Thread-Index: AccveLai4UDi/iBnQUeUrv4IXLkHMQAAbNfQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, Thanks. Ok, I'm starting to get on the same page as you (I hope). > Mark, nobody is doubting tha it's attractive to be able to provide > third party evidence of what happened in a given transaction. That's > why so much work has been put into digitally signing application > layer traffic. The question at hand is where in the stack this > functionality should go. Again, I think the 00 and 01 drafts are unclear in places. I'm going to present a sunny-day scenario and try to consider the applications' perspectives too. Hopefully this will flush out where the app could benefit and if the app-over-TLS Evidence API is clunky. In this example I will provisionally DROP the four alerts (start1, start2, end1, end2). They aren't needed in this example I've suggested it as an option earlier. * Indicates optional or situation-dependent messages that are not always sent. + Indicates messages optional to the TLS handshake that MUST be sent when using TLS evidence. CLIENT SERVER ====================== ======================= ClientHello --------> ServerHello Certificate+ ServerKeyExchange* CertificateRequest+ <-------- ServerHelloDone Certificate+ ClientKeyExchange CertificateVerify+ ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished At this point, ClientHello included a request for the entire session to use TLS Evidence, and the ServerHello must have agreed. Otherwise, this handshake would have terminated after the Hellos. Also, mutual authentication must also have been successful. All of this must be true before the Finished messages indicate that a TLS evidence session is born. Since I've run this example while dropping alerts, no start1, etc. are required and all application data will generate evidence until the session is terminated. If alerts are dropped, then a fairly "safe" rule for evidence generation is to require that every time client or server dumps a stream of application data to TLS records and to the wire (a single TLS write call by the app) an EvidenceRequest also be created and sent. The TLS layer simply lets the app layer set the pace in this no-alerts proposal. Since I'm provisionally dropping alerts here, I think it's best to NOT reset the TLS Evidence application_data hashes any time during the session -- just let them accumulate across all Evidence- messages for the session. My example of this is shown below: ApplicationData-1 --------> [Client's instructions] EvidenceRequest-1 --------> <-------- EvidenceResponse-1 [Server's response] <-------- ApplicationData-2 <-------- EvidenceRequest-2 EvidenceResponse-2 --------> BTW, whether you run TLS Evidence with or without the four alerts (start1, etc.) you could have generated EvidenceResponse-1 and EvidenceResponse-2. To repeat from -00 and -01, the EvidenceRequest is just one party's opinion and signature, but EvidenceResponse proves that both parties independently computed the same hash over all the data fields as proscribed by TLS Evidence. So you EvidenceRequest is superseded (it's pretty much worthless to you) if you get a corresponding EvidenceResponse back. I think there's two aspects of whether this serves the application, or if it would be better for the apps to do the signatures at the app layer. First, is either client or server is sticking its neck out during this protocol? Second, how does the app need to configure and interact with the TLS layer to get this done? I don't think either client or server is exposing itself to undue risk when they use TLS Evidence. TLS Client sends its app data, and when the buffer it shares with TLS is empty, TLS automatically sends the EvidenceRequest-1. This is basically a hash over the handshake, a hash over the app data sent (yours) and received (none), a best-effort timestamp, etc., all digitally signed by client. My opinion is that the more specific client can be, the less likely this digital signature can be abused later (threats of replay, misappropriating the signature for some other purpose, etc.). TLS Server replies with EvidenceResponse-1, even before its application has looked at the application data. Server simply says, yes, I saw the same thing within the same session (and the timestamp looks like a best effort). Next, the server app handles the data it just received from the TLS layer as input, then it may have some output data. The server app puts its output data into a buffer and gives that to the TLS layer. Now the TLS server sends that app data and automatically chases it with EvidenceRequest-2. Inside EvidenceRequest-2, there's a hash of the app_data sent and received, etc., plus the TLS server's signature over the whole EvidenceRequest-2. Finally, TLS client replies with EvidenceResponse-2, proving that client saw what server sent. Threats I've considered include: client or server "hangs up" at an opportune moment in the exchange, one sends garbage, one sends something unexpected in the app data. I think all of these threats pose little risk to the parties because of two facts. 1) before either party gets their EvidenceResponse, they can walk away and claim "it didn't happen." 2) once one or more EvidenceResponses exist, these become an "I know you know" checkpoint that both parties can roll back to. I hope what I've said so far clarifies the -00 and -01 drafts, and also presents opportunity for discussion and improvement. Since this email is already long, let me use anther email for "How does the app need to configure and interact with the TLS layer to get this done?" Thanks, -mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 17:55:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F1A-0005gd-Jz; Wed, 03 Jan 2007 17:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F19-0005gX-87 for tls@ietf.org; Wed, 03 Jan 2007 17:55:31 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2F17-0006Mc-ST for tls@ietf.org; Wed, 03 Jan 2007 17:55:31 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id XAA23475; Wed, 3 Jan 2007 23:55:18 +0100 (MEZ) From: Martin Rex Message-Id: <200701032255.XAA15968@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Wed, 3 Jan 2007 23:55:18 +0100 (MET) In-Reply-To: <002401c72f6f$5269f6e0$6801a8c0@rps.local> from "Mark Brown" at Jan 3, 7 01:42:37 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Here's an example to motivate why someone might want an un-forgeable record. > Say you're buying tickets to a popular concert/movie/etc. online (i.e., > limited inventory situation). In this case you (buyer) might care even more > about getting a ticket than its price. So when you show up at the venue you > want your electronic tickets / records of sale sustain a fair verification > effort that they are not forgeries. You do not want the venue manager to > say, "Sorry, we don't have records of this transaction..." Sorry, but this is complete bullshit. Browsers traditionally use up to 4 independent connections to retrieve parts of what composes a Web page as seen by the user, and that results in several parallel independent TLS-protected communcation channels. Similar things happens in the middleware of other applications. The majority of online-shops uses a crazy amount of http gimicks to beef up their web-pages, including CSS and javascript, and you don't seem to have looked at the raw source code of any of that stuff lately, or you would know that this stuff is close to incomprehensible at the network level. Implementing some visualization software to make sense from the captures&signed fraction of a raw datastream will require magnitudes more code&time than implementing digital signatures in a clean an understandable way at the application level and the signed data can be made comprehensible for mere mortals in raw form or compatible and verifyable with standardized software (i.e. PKCS#7 / CMS). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 17:57:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F2r-0006M2-U7; Wed, 03 Jan 2007 17:57:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F2q-0006Lw-HN for tls@ietf.org; Wed, 03 Jan 2007 17:57:16 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2F2p-0006vl-5P for tls@ietf.org; Wed, 03 Jan 2007 17:57:16 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 482A41E8C28; Wed, 3 Jan 2007 14:57:14 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <003301c72f87$ba822410$6801a8c0@rps.local> From: Eric Rescorla Date: Wed, 03 Jan 2007 14:57:14 -0800 In-Reply-To: <003301c72f87$ba822410$6801a8c0@rps.local> (Mark Brown's message of "Wed, 3 Jan 2007 16:37:19 -0600") Message-ID: <86vejn3eid.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: > Since I've run this example while dropping alerts, no start1, etc. are > required and all application data will generate evidence until the session > is terminated. If alerts are dropped, then a fairly "safe" rule for > evidence generation is to require that every time client or server dumps a > stream of application data to TLS records and to the wire (a single TLS > write call by the app) an EvidenceRequest also be created and sent. Yes, but how does the *app* know that? > The TLS > layer simply lets the app layer set the pace in this no-alerts proposal. > Since I'm provisionally dropping alerts here, I think it's best to NOT reset > the TLS Evidence application_data hashes any time during the session -- just > let them accumulate across all Evidence- messages for the session. My > example of this is shown below: > > ApplicationData-1 --------> [Client's instructions] > EvidenceRequest-1 --------> > <-------- EvidenceResponse-1 > [Server's response] <-------- ApplicationData-2 But there's a race condition here. The server doesn't know that an EvidenceRequest-1 message is coming, so how does it know to wait for it before executing whatever transaction the client requested? Remember that TLS is a stream protocol, so the only boundaries are at the higher layer. If the server wants to follow the (reasonable) policy of not performing any actions until after he's received signed instructions from the client, then he has to block waiting for the client to generate a signature. At minimum this requires interaction with the app because (again) the TLS stack doesn't know. Moreover, without some external agreement about how often these are generated, you can get a deadlock. Now, the server could certainly ask for a signature by sending his own Evidence-Request, but now you're requiring app interaction. > Threats I've considered include: client or server "hangs up" at an opportune > moment in the exchange, one sends garbage, one sends something unexpected in > the app data. I think all of these threats pose little risk to the parties > because of two facts. > > 1) before either party gets their EvidenceResponse, they can walk away and > claim "it didn't happen." But transaction rollbacks are expensive and complicated. It's much better to simply not perform the transaction if the counterparty hasn't authenticated. Moreover, in this system you *need* to treat a failed evidence handshake (e.g., due to network failures) as an attack and execute a transaction rollback. With ordinary signed messages this isn't true since a network failure just causes the counterparty not to get their receipt. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 03 20:29:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HPQ-0002LM-QU; Wed, 03 Jan 2007 20:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HPP-0002FC-KL; Wed, 03 Jan 2007 20:28:43 -0500 Received: from stratton-one-sixteen.mit.edu ([18.187.5.116] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HPO-0007yP-EN; Wed, 03 Jan 2007 20:28:43 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 52D54E00B4; Wed, 3 Jan 2007 20:28:42 -0500 (EST) To: saag@mit.edu From: Sam Hartman Message-Id: <20070104012842.52D54E00B4@carter-zimmerman.mit.edu> Date: Wed, 3 Jan 2007 20:28:42 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, ietf-sasl@imc.org, tls@ietf.org Subject: [TLS] Writing Help with draft-williams-on-channel-binding X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org There was a lively discussion here of draft-williams-on-channel-binding. After revising the draft based on comments received, Nico has submitted it for publication. I've sent him some minor AD review comments; once he addresses them I think the document will be ready for last call. However, I think we could make it significantly better. The problem is that several of us have been thinking about channel binding for the last couple of years. We've got it stuck in our minds. The current draft speaks well to what we're looking for. However it isn't as good of an introduction to the concept as it could be. It does a good job of specifying requirements for channel binding values and mechanisms that use channel binding. Is there someone out there who is a reasonably good writer but who has not been heavily involved in the channel binding discussion who would be willing to commit some significant time over the next month or so to understand and improve the draft? If you would be interested please let Nico and I know. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 08:27:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Sbw-0002F6-Bc; Thu, 04 Jan 2007 08:26:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Sbv-0002Ez-2p for tls@ietf.org; Thu, 04 Jan 2007 08:26:23 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Sbt-0003GT-Je for tls@ietf.org; Thu, 04 Jan 2007 08:26:22 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id OAA22507; Thu, 4 Jan 2007 14:25:55 +0100 (MEZ) From: Martin Rex Message-Id: <200701041325.OAA27181@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 4 Jan 2007 14:25:54 +0100 (MET) In-Reply-To: <002401c72f6f$5269f6e0$6801a8c0@rps.local> from "Mark Brown" at Jan 3, 7 01:42:37 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Here's an example to motivate why someone might want an un-forgeable record. > Say you're buying tickets to a popular concert/movie/etc. online (i.e., > limited inventory situation). In this case you (buyer) might care even more > about getting a ticket than its price. So when you show up at the venue you > want your electronic tickets / records of sale sustain a fair verification > effort that they are not forgeries. You do not want the venue manager to > say, "Sorry, we don't have records of this transaction..." There is a real-world example of how to make correct use of digital signatures as a legal proof. Unfortunately the entire description is in German, so not everyone will understand what this is about: http://faq.1und1.de/access/neu/vertrags_und_rechnungsfragen_/3.html This is about a German Internet Service Provider that offers to send Email-based (instead of paper-based) invoices to business customers and they offer a discount for using that service (because printing and Snail mailing generates more cost that the purely digital approach). Now the issue is, that in order for a business to get VAT refund from the IRS, a business either needs to turn in a paper-based invoice or alternatively a digital invoice with a qualified digital signature that conforms to the German digital signature law. So the approach taken by that Internet Service Provider is to send the invoice as a digitally signed PDF using a qualified digital signature, and they tell you on their Website (URL above) how to actually verify that qualified digital signature. "Evidence" at the raw network level for such a purpose is such a horribly stupid idea. I don't understand why we are wasting any time talking about it. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 09:40:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TlA-0005ZD-38; Thu, 04 Jan 2007 09:40:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Tl9-0005Z8-4I for tls@ietf.org; Thu, 04 Jan 2007 09:39:59 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Tl6-0007jg-Rz for tls@ietf.org; Thu, 04 Jan 2007 09:39:59 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id EF31E820F; Thu, 4 Jan 2007 08:39:55 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Thu, 4 Jan 2007 08:41:28 -0600 Message-ID: <003c01c7300e$6b675d00$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200701032255.XAA15968@uw1048.wdf.sap.corp> Thread-Index: AccvikQ6GNFDf45FT02La4O1Yd6GhAAeolHA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, I think you're concerned about the HTTP GET side of my illustration, whereas TLS Evidence here would be concerned about the POST. I'm Ok to assume HTTP is the app as you do: > Browsers traditionally use up to 4 independent connections to retrieve > parts of what composes a Web page as seen by the user, and that results > in several parallel independent TLS-protected communcation channels. I also agree with you that what is "seen by the user" may be the assembly of multi connections' GETs within the browser (etc.). But TLS Evidence doesn't worry about that; what is "seen by the user" is simply out of scope. TLS Evidence only creates a factual record of what sent and received if and only if both parties digitally sign the same hash values (hashes over the sent and received data). The POST is the target for TLS Evidence in this illustration. And instead of generating a lot of useless evidence like "user fetched another JPEG" (app designer's choice here; I'm just making a suggestion), it would be more efficient to only capture TLS Evidence over something like the last step of a "checkout" sequence. Specifically, app designers should use/require TLS Evidence for precisely those outputs/pages of the app where the app server generates and returns to the client the "ticket" in response to the client's input. In HTTP usage, that's when the buyer (controlling the stack from user agent down, including TLS) creates a new HTTPS/TLS/TCP/IP session, specifies the use of TLS Evidence in the ClientHello, and then uses HTTP to send all of the current page's cookies, visible field data, hidden field data, etc. to the web server as POSTDATA, and then receives the web server's response. Typically that HTTP session would be immediately torn down at this point. The TLS Evidence generated in this illustration would show what the client sent in POSTDATA and how the web server responded to the POST, i.e., the HTTP application data that the app server gave back in response to the POSTDATA. Within this illustration's parameters, that reply app data will either contain the "ticket" or some sort of an error message. That's due to the app designer's choice of when to require use of TLS Evidence. The point of TLS Evidence's use within this illustration is that anyone, even a third party, can easily show that a particular web server gave some app data to a particular client (to the extent the PKCs can show authenticity), and that app data is not a forgery (unless the digital signature crypto was cracked). The goal here is not perfection, but to still be helpful. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 10:31:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UYw-0003bm-Q3; Thu, 04 Jan 2007 10:31:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UYu-0003Y8-M2 for tls@ietf.org; Thu, 04 Jan 2007 10:31:24 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2UYt-0006Ta-9q for tls@ietf.org; Thu, 04 Jan 2007 10:31:24 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA26159; Thu, 4 Jan 2007 16:30:02 +0100 (MEZ) From: Martin Rex Message-Id: <200701041529.QAA29263@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 4 Jan 2007 16:29:55 +0100 (MET) In-Reply-To: <003c01c7300e$6b675d00$6801a8c0@rps.local> from "Mark Brown" at Jan 4, 7 08:41:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > The point of TLS Evidence's use within this illustration is that anyone, > even a third party, can easily show that a particular web server gave some > app data to a particular client (to the extent the PKCs can show > authenticity), and that app data is not a forgery (unless the digital > signature crypto was cracked). The goal here is not perfection, but to > still be helpful. The point is, that this is entirely pointless. TLS is typically used on a hop-by-hop basis, and the only connection where it would make any sense is the one between the last hop on the client side and the initial entry point to the server side. In pretty much every serious deployment the front-door of a business system runs on a host in the DMZ, and the only "valuable" thing that this possesses is a keypair suitable for online authentication of the server. A business/organization would be quite stupid to deploy keys with digital signature capabilities in any legally binding sense on such a host. Furthermore: The last two Online-shops where I ordered computer parts explicitly indicated that neither the successful completion of the "checkout", and not even the "autometic confirmation email" sent as a result of the checkout would be legally binding in any way for them to ship the requested product for the displayed amount and conditions. Only an explicit confirmation Email generated in their backend system (usually sent within a business day) will confirm the contract. (I don't know whether those involve human action(s). TLS-based Evidence would be entirely useless in these scenarios, because they already have had issues when the intermediate/frontend systems failed (or were hacked), and the businesses don't want to be held responsible for that. A very common error is a typo in the price of the web shop, and it did happen to companies like Dell. It would be a pretty stupid idea to include the easiest and well known point of failure (and point of attack) into the creation of legally binding digital signatures. TLS/SSL has been about online authentication, and it should firmly stick to that archtecture. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 12:05:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2W1v-0005Wl-1n; Thu, 04 Jan 2007 12:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2W1t-0005UG-PQ for tls@ietf.org; Thu, 04 Jan 2007 12:05:25 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2W1s-0008Fl-2x for tls@ietf.org; Thu, 04 Jan 2007 12:05:25 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 06CA4824A; Thu, 4 Jan 2007 11:05:22 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Thu, 4 Jan 2007 11:06:44 -0600 Message-ID: <004701c73022$bc8ae8f0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200701041529.QAA29263@uw1048.wdf.sap.corp> Thread-Index: AccwFWKZkB5CNDhBRker0Lj3R80zHAAAjWJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Personally, I can see how it could be to the seller's advantage to not print receipts that customers could use -- that way, they can avoid being held accountable. > The last two Online-shops where I ordered computer parts explicitly > indicated that neither the successful completion of the "checkout", > and not even the "autometic confirmation email" sent as a result of > the checkout would be legally binding in any way for them to ship > the requested product for the displayed amount and conditions. > > Only an explicit confirmation Email generated in their backend > system (usually sent within a business day) will confirm the > contract. (I don't know whether those involve human action(s). However, some buyers might want a solid receipt when making purchases. Not a receipt like the email you mention, since it really is not a sure thing that the email will ever get to you or contain accurate information. If used, TLS Evidence could do a better job at receipts than this email system you mention. Regarding security, you raise a good point: > In pretty much every serious deployment the front-door of a business > system runs on a host in the DMZ, and the only "valuable" thing > that this possesses is a keypair suitable for online authentication > of the server. A business/organization would be quite stupid to > deploy keys with digital signature capabilities in any legally > binding sense on such a host. ... > TLS-based Evidence would be entirely useless in these scenarios, > because they already have had issues when the intermediate/frontend > systems failed (or were hacked), and the businesses don't want to > be held responsible for that. A very common error is a typo in > the price of the web shop, and it did happen to companies like Dell. > > It would be a pretty stupid idea to include the easiest and well > known point of failure (and point of attack) into the creation > of legally binding digital signatures. "Legally binding" is out of scope, but the issue about DMZ is a good security question. Using a DMZ or another kind of strong separation (for example partitions in a MILS separation kernel) is the reason that TLS Evidence allows the PKC used for TLS session authentication to be different from the PKC used for signing the Evidence- structures. However, separating out the signing component (the TLS Evidence handler) from the TLS layer is probably overkill for commercial applications. Why? Because no one can generate TLS Evidence by compromising only the server's private keys. TLS EvidenceResponse structures are only valid after both TLS client and TLS server have signed them. So for your scenario to generate valid TLS Evidence you need the attacker to have compromised the TLS server's authentication key and evidence key (they may be one and the same though) and to have possession of the client's authentication key and evidence key (they may be one and the same). This is not very feasible unless the attacker is the client. So let's say the attacker compromises the TLS server and both keys and copies these down to his lab. In the lab, the attacker generates a TLS session with mutual authentication and TLS Evidence in play, dummies up a request for a ticket that looks realistic, and dummies up a response that also looks realistic. Now we have a forged ticket signed by the real server's PKC and a dummy client PKC. The attacker knows that just about anyone could check the TLS Evidence later. So the attacker needs to make some hard choices. Should the attacker get the dummy client PKC signed by a CA? Should the dummy client PKC be signed by a CA that the TLS server trusts -- perhaps a CA that charges money for its PKCs, or perhaps a CA operated by the TLS server's organization? Perhaps the app server shows the last 4 digits of a credit card number used to pay for the ticket on all real receipts -- should the attacker use a real credit card number in the app data sent in the lab? Now that credit card info is part of the TLS Evidence record. Or perhaps the app server requires the buyer to send in his/her name to be printed on the ticket receipt -- should the attacker use a real name? Etc. The attacker would have to be pretty bold to use a PKC with his real name and/or embed a real credit card number into the app data signed by TLS Evidence. If a credit card number was used, a suspicious third party could check to see if the charge actually went through. In a dispute, a third party might ask for secondary identification -- show me the credit card, show me your driver's license -- if forgery was suspected (the attacker did grab both private keys from the TLS server by force...). On the other hand, you could buy a server certified at EAL6+ to do the TLS and TLS Evidence for you, and that would make the foregoing discussion moot by today's standards. Key compromise of an EAL6+ box is supposed to be pretty hard to do. In any case, TLS Evidence makes no guarantees about the law / legality, or that it prevents crime, etc. What it does is to use cryptography to make forgery more difficult. This could be useful to applications. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 13:03:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WvT-0001eD-T1; Thu, 04 Jan 2007 13:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WvR-0001dk-Qc for tls@ietf.org; Thu, 04 Jan 2007 13:02:49 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WvP-00046O-Bi for tls@ietf.org; Thu, 04 Jan 2007 13:02:49 -0500 Received: by wx-out-0506.google.com with SMTP id h27so6644129wxd for ; Thu, 04 Jan 2007 10:02:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ngsFSFwmr7zPqlJSma5QUmO5EkLwPzj0nj4rVbMd7Md9s9W+I+4dat1S0RE8+OrMVoc2kXj9/GABaJhnu/0aqGfdCqCfb+8JpQxza+m4ZeOcTKbT1pg9YFaNZMZHbxaARXpBLwWE6uEs+OAZj/7h7ViU9qIbzY8Iz8MkMSLivo4= Received: by 10.90.88.13 with SMTP id l13mr361256agb.1167933767112; Thu, 04 Jan 2007 10:02:47 -0800 (PST) Received: by 10.90.56.2 with HTTP; Thu, 4 Jan 2007 10:02:47 -0800 (PST) Message-ID: <6b9359640701041002n3e61bd4fx7a3caa0db891c824@mail.gmail.com> Date: Thu, 4 Jan 2007 11:02:47 -0700 From: "Kyle Hamilton" To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 In-Reply-To: <004701c73022$bc8ae8f0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701041529.QAA29263@uw1048.wdf.sap.corp> <004701c73022$bc8ae8f0$6801a8c0@rps.local> X-Spam-Score: 1.1 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 1/4/07, Mark Brown wrote: > > Why? Because no one can generate TLS Evidence by compromising only the > server's private keys. TLS EvidenceResponse structures are only valid after > both TLS client and TLS server have signed them. So for your scenario to > generate valid TLS Evidence you need the attacker to have compromised the > TLS server's authentication key and evidence key (they may be one and the > same though) and to have possession of the client's authentication key and > evidence key (they may be one and the same). This is not very feasible > unless the attacker is the client. Isn't the entire point of an attack to harm the attacked? Motives differ for attacks. The motives for attacks help describe/define what attack is going to be carried out, and how. As an example, let's look at the "disgruntled employee" concept. Sysadmin, disgruntled, has possession of the traffic and signature-evidence keys, as he's responsible for making sure they get into the correct place and are used in the correct manner. Owner or CFO or whathaveyou overlook this during employment/contract termination. (Which is ASTOUNDINGLY easy to do.) Bingo, you suddenly have an attack against your business's legal existence. > The attacker knows that just about anyone could check the TLS Evidence > later. So the attacker needs to make some hard choices. Should the > attacker get the dummy client PKC signed by a CA? Should the dummy client > PKC be signed by a CA that the TLS server trusts -- perhaps a CA that > charges money for its PKCs, or perhaps a CA operated by the TLS server's > organization? Perhaps the app server shows the last 4 digits of a credit > card number used to pay for the ticket on all real receipts -- should the > attacker use a real credit card number in the app data sent in the lab? Now > that credit card info is part of the TLS Evidence record. Or perhaps the > app server requires the buyer to send in his/her name to be printed on the > ticket receipt -- should the attacker use a real name? Etc. Should the attacker put an alternate server up, make it look like the real thing, be authenticable as it... and let others connect to it without realization that it's fake? > The attacker would have to be pretty bold to use a PKC with his real name > and/or embed a real credit card number into the app data signed by TLS > Evidence. If a credit card number was used, a suspicious third party could > check to see if the charge actually went through. In a dispute, a third > party might ask for secondary identification -- show me the credit card, > show me your driver's license -- if forgery was suspected (the attacker did > grab both private keys from the TLS server by force...). Or, be bold enough to let others do it. Every one of the transactions is individually actionable, and that can cripple a business with legal fees. > On the other hand, you could buy a server certified at EAL6+ to do the TLS > and TLS Evidence for you, and that would make the foregoing discussion moot > by today's standards. Key compromise of an EAL6+ box is supposed to be > pretty hard to do. ...except by people who have access regardless. > In any case, TLS Evidence makes no guarantees about the law / legality, or > that it prevents crime, etc. What it does is to use cryptography to make > forgery more difficult. This could be useful to applications. This is not something that can be solved at the network layer. It's an application issue, and needs to be dealt with as such. -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 13:13:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X5Q-0007qr-8L; Thu, 04 Jan 2007 13:13:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X5P-0007qm-8N for tls@ietf.org; Thu, 04 Jan 2007 13:13:07 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2X5J-0005s7-PF for tls@ietf.org; Thu, 04 Jan 2007 13:13:07 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA22623; Thu, 4 Jan 2007 19:12:50 +0100 (MEZ) From: Martin Rex Message-Id: <200701041812.TAA01659@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 4 Jan 2007 19:12:49 +0100 (MET) In-Reply-To: <004701c73022$bc8ae8f0$6801a8c0@rps.local> from "Mark Brown" at Jan 4, 7 11:06:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Personally, I can see how it could be to the seller's advantage to not print > receipts that customers could use -- that way, they can avoid being held > accountable. You get it wrong. It is about businesses not wanting binding digital signatures on data that has been produced by the most untrusted equipment on their premises -- the machines in the DMZ. It will cost you big bucks to have any such signatures created on a EAL6+ certified piece of hardware, but that doesn't really fix the real problem -- that the signatures will get applied to transactions processed by a fancy web-shop (frontend) running on LAMP or IIS and with pricing information that a vendor must consider about as accurate as on printed advertisement. The possibility to steal signature keys is just one aspect of the security problems around the TLS Evidence proposal. The larger problem is about the data that gets signed and the interpretation of that data. An attacker doesn't need to compromise/steal the keys if he can get data of his choice signed, e.g. by by subverting the vendors web shop application or by subverting the entire client software (e.g. a trojan using cross-site scripting of some sort). > > However, some buyers might want a solid receipt when making purchases. Not > a receipt like the email you mention, since it really is not a sure thing > that the email will ever get to you or contain accurate information. If > used, TLS Evidence could do a better job at receipts than this email system > you mention. PKCS#7 / CMS, signed PDF, XMLsig, whathave you are all readily available. See https://www.global-esign.com/ for verification of legally binding digital signatures by a government accredited CA on CMS and signed PDFs (as for the Invoices of the German Internet Service Provider I mentioned). SSL/TLS client certificates are still rare these days, and using them for (legally binding) digital signatures would be a pretty dumb idea security-wise. One conceivable approach would be to use for secure client-side digital signatures would be an EAL6+ certified USB-gadget with its own TFT-display, keypad and crypto modules/key storage that can display (pure text-based) contractual data and allow the user to apply individual digital signatures only on small, known and trusted pieces of information as displayed on the screen of the gadget. That should be doable in the OLPC price range, and be fairly secure even for home users running MSIE on Microsoft Windows on a regular PC. TLS Evidence is a flawed approach, because what is signed there is a client software from software vendor A, usually completely outside of control of an end-user B, talking to an (application) server software for vendor X supplied by software vendor Y, and usually neither user B nor vendor X are aware what information is really exchanged (and signed) at the network level and how much of their (conscious) actions has what kind of impact on what gets sent and signed. It would hardly help them to know, since it largely depends on what software vendors A and Y ship and whether their software or machine has been trojaned/XSSd/hacked. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 13:58:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xmu-0001Z9-PJ; Thu, 04 Jan 2007 13:58:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xmt-0001Z4-La for tls@ietf.org; Thu, 04 Jan 2007 13:58:03 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Xms-00052F-7H for tls@ietf.org; Thu, 04 Jan 2007 13:58:03 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id TAA00178; Thu, 4 Jan 2007 19:57:46 +0100 (MEZ) From: Martin Rex Message-Id: <200701041857.TAA02261@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: ekr@networkresonance.com Date: Thu, 4 Jan 2007 19:57:46 +0100 (MET) In-Reply-To: <86vejn3eid.fsf@raman.networkresonance.com> from "Eric Rescorla" at Jan 3, 7 02:57:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > Mark Brown wrote: > > The TLS > > layer simply lets the app layer set the pace in this no-alerts proposal. > > Since I'm provisionally dropping alerts here, I think it's best to NOT reset > > the TLS Evidence application_data hashes any time during the session -- just > > let them accumulate across all Evidence- messages for the session. My > > example of this is shown below: > > > > ApplicationData-1 --------> [Client's instructions] > > EvidenceRequest-1 --------> > > <-------- EvidenceResponse-1 > > [Server's response] <-------- ApplicationData-2 > > But there's a race condition here. The server doesn't know that > an EvidenceRequest-1 message is coming, so how does it know > to wait for it before executing whatever transaction the client > requested? Remember that TLS is a stream protocol, so the only > boundaries are at the higher layer. > > If the server wants to follow the (reasonable) policy of not > performing any actions until after he's received signed instructions > from the client, then he has to block waiting for the client to > generate a signature. At minimum this requires interaction with the app > because (again) the TLS stack doesn't know. Moreover, without > some external agreement about how often these are generated, > you can get a deadlock. Now, the server could certainly ask for > a signature by sending his own Evidence-Request, but now you're > requiring app interaction. In many existing deployments its even magnitudes more complicated, and it becomes exteremly obvious that TLS Evidence doesn't fit at all into the TLS architecture. Think about reverse proxies, "SSL accelerators", load balancers, which are the entry point to application server farms today and terminate the SSL/TLS connection and forward optional SSL/TLS client certificates as header fields to the backend application engines through various kinds of communication, and sometimes doing request aggregation on the way. If the application on the backend system would like to get "Evidence" of a transaction using TLS evidence, it will have to jump many hoops to (a) get signalling to the SSL/TLS terminating host/component in the opposite direction of the regular communication and also how to get that data re-transferred once it is collected. Considering that it took Microsoft about >10 years after it was standardized in the spec to actually support SSL/TLS client certificates in WinHTTP (I don't know whether the hotfix is generally available yet), I have little hope of an Evidence concept requiring client certificates to go anywhere fast. If you do consider "Evidence" for customers of Web Shops / Online Services useful, then a proposal that can not do without client certs is a pretty dumb approach. The use of client certs is still extremely limited, otherwise the shortcomings in Microsoft's WinHTTP would have been noticed and fixed long before shipment. As has been said before, secure receipts can be easily implemented with the existing technology, with only a small application plugin at the backend side and no changes to the middleware and no changes to the client software. Actually, several solutions are in active use for over a year, some even with truely legally binding digital signatures! -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 14:21:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Y9C-0008P7-Ry; Thu, 04 Jan 2007 14:21:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Y9B-0008P1-S6 for tls@ietf.org; Thu, 04 Jan 2007 14:21:05 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Y99-0001LK-FG for tls@ietf.org; Thu, 04 Jan 2007 14:21:05 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA20163; Thu, 4 Jan 2007 20:20:57 +0100 (MEZ) From: Martin Rex Message-Id: <200701041920.UAA02611@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 4 Jan 2007 20:20:57 +0100 (MET) In-Reply-To: <003c01c7300e$6b675d00$6801a8c0@rps.local> from "Mark Brown" at Jan 4, 7 08:41:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > I think you're concerned about the HTTP GET side of my illustration, whereas > TLS Evidence here would be concerned about the POST. I'm Ok to assume HTTP > is the app as you do: > > > Browsers traditionally use up to 4 independent connections to retrieve > > parts of what composes a Web page as seen by the user, and that results > > in several parallel independent TLS-protected communcation channels. > > I also agree with you that what is "seen by the user" may be the assembly of > multi connections' GETs within the browser (etc.). But TLS Evidence doesn't > worry about that; what is "seen by the user" is simply out of scope. OUCH. OUCH. OUCH. > > TLS Evidence only creates a factual record of what sent and received > if and only if both parties digitally sign the same hash values > (hashes over the sent and received data). > > The POST is the target for TLS Evidence in this illustration. And instead > of generating a lot of useless evidence like "user fetched another JPEG" > (app designer's choice here; I'm just making a suggestion), it would be more > efficient to only capture TLS Evidence over something like the last step of > a "checkout" sequence. This is a totally flawed and insane approach! But on the other hand, it makes an interesting business model: As a Vendor, I can create (textual pages) with an order containing the real price that I want to get signed (1,499,999.-) and I use gifs to overlay this price in the form displayed to the user with the background colour, so that the user sees (99,999.-). Now in your model, the TLS Evidence is produce over the full amount, while the information that the user saw, and what he intended to sign, was a MUCH smaller amount. Unfortunately, even if the user did make a screen-cap -- the screen cap is unsigned, the gifs overlaying the three leading characters of the full price are not part of the TLS Evidence, but the full amount is part of the TLS Evidence. Now if the TLS Evidence proposal leads to so many seriously flawed "application solutions" from people discussing with the security geeks on tls@ietf.org, how much worse will be the outcome of applications using TLS Evidence designed by the masses of security-unconscious application writers out there? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 15:20:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Z3w-0002Ev-J8; Thu, 04 Jan 2007 15:19:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Z3v-0002El-IE for tls@ietf.org; Thu, 04 Jan 2007 15:19:43 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Z3t-0000ZO-IJ for tls@ietf.org; Thu, 04 Jan 2007 15:19:42 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id B3C448258; Thu, 4 Jan 2007 14:19:38 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Thu, 4 Jan 2007 14:21:11 -0600 Message-ID: <005a01c7303d$e081cdd0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200701041812.TAA01659@uw1048.wdf.sap.corp> Thread-Index: AccwK/cOdC+yNwSpQea1njRccTJoRgAAhCIw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, > An attacker doesn't need to > compromise/steal the keys if he can get data of his choice > signed... Here's how to get useful data of your choice signed using TLS Evidence: spoof the app server to the server-side TLS layer. Attacker could lurk around in the DMZ and intercept calls to the app server, impersonate the app server, and send data of your choice back to the TLS layer that's doing TLS Evidence. A simple deterrent: use IPsec between the DMZ-located TLS box and the app server on the internal network. Stronger approaches could be used. Except for out of band (out of TLS session) subversion attacks or straight impersonation (as above), it's not realistic to believe an attacker can obtain useful, doubly-signed TLS Evidence for data of his choice. TLS Evidence is hard to forge and similarly hard to create for data of your choice. If the attacker can succeed in an out-of-band subversion effort, then it's probably easier for an attacker just to bypass TLS Evidence and go straight at the web app or system of record on the internal network. In these cases there's no TLS Evidence at all -- and you may have bigger problems on your hands. Let's say the attacker doesn't compromise the TLS server's keys, but wants to subvert the web app in-band. So the attacker attacks the app server while using TLS Evidence. If so, the TLS Evidence will show what the attacker sent (the message that subverted the web app) and what the attacker received (a ticket). So if the server retains the TLS Evidence then they can show who subverted the app and how they did it -- with the attacker's own signature. That would be a dumb move on the attacker's part, i.e., "Here's evidence of how I subverted your server and extracted a ticket -- now give me my reward." Does your attacker prefer civil or criminal legal problems? Let's say the attacker also destroys the server's TLS Evidence -- well, does the attacker retain his own copy? Does the attacker show his TLS Evidence later when the server app's organization has no record of the ticket? If the attacker destroys all copies of the TLS Evidence, then it can't be used in any attack, defense, etc. If the attacker just subverts the client, then the server app won't think that the attacker/client has paid for the ticket and won't issue the ticket. Where's the attack? Does the attacker pull out his own credit card and pay for the ticket, via the subverted client? Then the evidence will show it. The subverted client will sign it, and the server will verify that the signature is correct -- all before the ticket gets created or sent. Are there better attacks to get data of the attacker's choice both TLS Evidence-signed and useful to the attacker? > See https://www.global-esign.com/ > for verification of legally binding digital signatures by a > government accredited CA on CMS and signed PDFs (as for the > Invoices of the German Internet Service Provider I mentioned). I am sure that TLS Evidence uses not rely on the German national CA law. TLS Evidence does not require a state-run Certificate Authority while the German approach you mention does. Because TLS is an International standard, it doesn't make sense to embed dependencies on German laws (or Utah laws, etc.) into TLS. Let's skip the legal discussion in this forum. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 15:27:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZAl-0007Be-1B; Thu, 04 Jan 2007 15:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZAj-0007BE-6w for tls@ietf.org; Thu, 04 Jan 2007 15:26:45 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZAO-0003NW-TL for tls@ietf.org; Thu, 04 Jan 2007 15:26:45 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 3B66E8206 for ; Thu, 4 Jan 2007 14:26:22 -0600 (CST) From: "Mark Brown" To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Thu, 4 Jan 2007 14:27:55 -0600 Message-ID: <005b01c7303e$d1030490$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccwNXno2IVZVD8cQjac4sIRr0+LOAAAM85gAAIdzjA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Isn't this attack possible with today's web sales? I mean, once you give your credit card to anyone, can't they ring you out at any price they want? You don't need a website or TLS to do this attack. You can do this on the phone or via mail order. So in the case of TLS Evidence, you both have a record of (1,499,999.-) instead of what the buyer thought, (99,999.-). So what? In both cases the buyer cancels the order. You don't need TLS Evidence to cancel...with either the merchant or by contacting your credit card issuer. In both cases the buyer might want to go back to the website and get a screen capture, showing how the merchant is practicing fraud... This is really a legal issue with a merchant who is intending to defraud, and it would be pretty easy for anyone to verify. While hiding prices with GIFs is a deceptive practice that's probably illegal, I want to focus on protocol issues. --mark > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: Thursday, January 04, 2007 1:21 PM > To: Mark Brown > Cc: martin.rex@sap.com; tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 > > Mark Brown wrote: > > > > I think you're concerned about the HTTP GET side of my illustration, > whereas > > TLS Evidence here would be concerned about the POST. I'm Ok to assume > HTTP > > is the app as you do: > > > > > Browsers traditionally use up to 4 independent connections to retrieve > > > parts of what composes a Web page as seen by the user, and that > results > > > in several parallel independent TLS-protected communcation channels. > > > > I also agree with you that what is "seen by the user" may be the > assembly of > > multi connections' GETs within the browser (etc.). But TLS Evidence > doesn't > > worry about that; what is "seen by the user" is simply out of scope. > > OUCH. OUCH. OUCH. > > > > > > TLS Evidence only creates a factual record of what sent and received > > if and only if both parties digitally sign the same hash values > > (hashes over the sent and received data). > > > > The POST is the target for TLS Evidence in this illustration. And > instead > > of generating a lot of useless evidence like "user fetched another JPEG" > > (app designer's choice here; I'm just making a suggestion), it would be > more > > efficient to only capture TLS Evidence over something like the last step > of > > a "checkout" sequence. > > This is a totally flawed and insane approach! > > But on the other hand, it makes an interesting business model: > As a Vendor, I can create (textual pages) with an order containing > the real price that I want to get signed (1,499,999.-) and I use > gifs to overlay this price in the form displayed to the user with > the background colour, so that the user sees (99,999.-). > > Now in your model, the TLS Evidence is produce over the full amount, > while the information that the user saw, and what he intended to sign, > was a MUCH smaller amount. > > Unfortunately, even if the user did make a screen-cap -- the screen > cap is unsigned, the gifs overlaying the three leading characters > of the full price are not part of the TLS Evidence, but the full > amount is part of the TLS Evidence. > > > Now if the TLS Evidence proposal leads to so many seriously flawed > "application solutions" from people discussing with the security geeks > on tls@ietf.org, how much worse will be the outcome of applications > using TLS Evidence designed by the masses of security-unconscious > application writers out there? > > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 04 15:50:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXN-0002D6-KQ; Thu, 04 Jan 2007 15:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXH-000292-QP for tls@ietf.org; Thu, 04 Jan 2007 15:50:03 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZXF-0003lu-VA for tls@ietf.org; Thu, 04 Jan 2007 15:50:03 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA01125; Thu, 4 Jan 2007 21:49:57 +0100 (MEZ) From: Martin Rex Message-Id: <200701042049.VAA04275@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 4 Jan 2007 21:49:57 +0100 (MET) In-Reply-To: <005b01c7303e$d1030490$6801a8c0@rps.local> from "Mark Brown" at Jan 4, 7 02:27:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Isn't this attack possible with today's web sales? I mean, once you give > your credit card to anyone, can't they ring you out at any price they want? > You don't need a website or TLS to do this attack. You can do this on the > phone or via mail order. > > So in the case of TLS Evidence, you both have a record of (1,499,999.-) > instead of what the buyer thought, (99,999.-). So what? In both cases the > buyer cancels the order. You don't need TLS Evidence to cancel...with > either the merchant or by contacting your credit card issuer. No I am confused. Since you just completely disclaimed the usefulness of TLS evidence for just about every business application, what's left? I don't see anything besides law enforcement, and I have serious problems in making cleartext escrow plus digital signing of the communication an IETF working group item. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 12:35:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sxS-00060x-L6; Fri, 05 Jan 2007 12:34:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sxR-00060n-Uj for tls@ietf.org; Fri, 05 Jan 2007 12:34:21 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sxQ-0006iV-Ht for tls@ietf.org; Fri, 05 Jan 2007 12:34:21 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 5 Jan 2007 17:34:17 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 5 Jan 2007 17:34:17 +0000 From: Stefan Santesson To: "martin.rex@sap.com" , Mark Brown Date: Fri, 5 Jan 2007 17:34:12 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Index: AccwNaxCEu/P/COlQJqHuxpb3AhB+gAtmcSw Message-ID: References: <003c01c7300e$6b675d00$6801a8c0@rps.local> from "Mark Brown" at Jan 4, 7 08:41:28 am <200701041920.UAA02611@uw1048.wdf.sap.corp> In-Reply-To: <200701041920.UAA02611@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I don't think this discussion is fair to the proposal, but in a way it is w= hat I expected to see when bringing the concept of "evidence" to a TLS grou= p. If we leave the concept of evidence out of scope and leave it to the lawyer= s to worry about, is there any technical merits? There is one that I think we should consider. If a client or a server want = to ask its opponent to sign a portion of data, is there any alternative sol= utions that would work cross platforms. PKCS#7/CMS or XML digsig is not an answer as it only provides signature for= mat, it does not deal with the request and response logic. Going higher up closer to the application requires standardization of solut= ions based on vendor specific interpretation languages such as Java or .NET= . The balance is a delicate problem. But I'm sure that if there is a solution= that is technically sound from a protocol perspective, then there will be = a way to implemented in a sufficiently secure way for many usages. As to the security discussion earlier, a very common way to eliminate the i= nsecure DMZ is to publish the web server from a secure front end firewall h= olding and/or controlling the TLS keys. Unless you can hack that firewall y= ou won't get to the keys or the server app side of the information flow. In= any case, just because there is a way to implement a solution badly, does = not mean that there is no good way to do it. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 4 januari 2007 11:21 > To: Mark Brown > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 > > Mark Brown wrote: > > > > I think you're concerned about the HTTP GET side of my illustration, > whereas > > TLS Evidence here would be concerned about the POST. I'm Ok to > assume HTTP > > is the app as you do: > > > > > Browsers traditionally use up to 4 independent connections to > retrieve > > > parts of what composes a Web page as seen by the user, and that > results > > > in several parallel independent TLS-protected communcation > channels. > > > > I also agree with you that what is "seen by the user" may be the > assembly of > > multi connections' GETs within the browser (etc.). But TLS Evidence > doesn't > > worry about that; what is "seen by the user" is simply out of scope. > > OUCH. OUCH. OUCH. > > > > > > TLS Evidence only creates a factual record of what sent and received > > if and only if both parties digitally sign the same hash values > > (hashes over the sent and received data). > > > > The POST is the target for TLS Evidence in this illustration. And > instead > > of generating a lot of useless evidence like "user fetched another > JPEG" > > (app designer's choice here; I'm just making a suggestion), it would > be more > > efficient to only capture TLS Evidence over something like the last > step of > > a "checkout" sequence. > > This is a totally flawed and insane approach! > > But on the other hand, it makes an interesting business model: > As a Vendor, I can create (textual pages) with an order containing > the real price that I want to get signed (1,499,999.-) and I use > gifs to overlay this price in the form displayed to the user with > the background colour, so that the user sees (99,999.-). > > Now in your model, the TLS Evidence is produce over the full amount, > while the information that the user saw, and what he intended to sign, > was a MUCH smaller amount. > > Unfortunately, even if the user did make a screen-cap -- the screen > cap is unsigned, the gifs overlaying the three leading characters > of the full price are not part of the TLS Evidence, but the full > amount is part of the TLS Evidence. > > > Now if the TLS Evidence proposal leads to so many seriously flawed > "application solutions" from people discussing with the security geeks > on tls@ietf.org, how much worse will be the outcome of applications > using TLS Evidence designed by the masses of security-unconscious > application writers out there? > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 13:52:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uAd-0002nL-IB; Fri, 05 Jan 2007 13:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uAc-0002kn-9w for tls@ietf.org; Fri, 05 Jan 2007 13:52:02 -0500 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2uAb-00030q-0J for tls@ietf.org; Fri, 05 Jan 2007 13:52:02 -0500 Received: by wx-out-0506.google.com with SMTP id h27so6963230wxd for ; Fri, 05 Jan 2007 10:52:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ez8wRt4XZ619yU+iyPCPL3mQ8bQVpcuyXSWyhnRTxmfTZ/zZwb2jQPhemoGzEwOQJkP5uqOocm+BpdoRvWkUBmE+eXgamLSi/b2VHwufV3MJxWU/ZImK0LYgYufc3LXfjL/0ZG/8mFODz3RKm1yfAQdR6/IH8IjoEWUjze/N9j8= Received: by 10.90.86.10 with SMTP id j10mr991643agb.1168023120818; Fri, 05 Jan 2007 10:52:00 -0800 (PST) Received: by 10.90.56.2 with HTTP; Fri, 5 Jan 2007 10:52:00 -0800 (PST) Message-ID: <6b9359640701051052q6ba6466br82712e33e91698f3@mail.gmail.com> Date: Fri, 5 Jan 2007 11:52:00 -0700 From: "Kyle Hamilton" To: "Stefan Santesson" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003c01c7300e$6b675d00$6801a8c0@rps.local> <200701041920.UAA02611@uw1048.wdf.sap.corp> X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 1/5/07, Stefan Santesson wrote: > If we leave the concept of evidence out of scope and leave it to the lawyers to worry about, is there any technical merits? > > There is one that I think we should consider. If a client or a server want to ask its opponent to sign a portion of data, is there any alternative solutions that would work cross platforms. Sure, if you want to define a protocol for it and not "embrace and extend" the way that Microsoft is so fond of doing. > PKCS#7/CMS or XML digsig is not an answer as it only provides signature format, it does not deal with the request and response logic. ...and this is a problem how? Dealing with this in the network layer (since TLS is supposed to look like the network layer to its clients) is COMPLETELY not the correct way to do it -- perhaps a standardized and hardened HTTP-like protocol, but even that is outside of the realm of the TLS working group. "I want this signed" is an application-transport mechanism, not a network mechanism. (No matter that MS implemented "signed CIFS" and "signed RPC", those standards aren't available cross-platform.) > Going higher up closer to the application requires standardization of solutions based on vendor specific interpretation languages such as Java or .NET. No, it requires standardization of solutions based on the protocol communication. Implementation of the protocol can be done in Java or C# (.NET isn't a language, it's a runtime) or C++ or whatever is appropriate for the implementation. The Internet is computer-language-agnostic -- it's recognized as "existing" simply because implementation cannot be done without it, but if it was reliant on C then you wouldn't be able to use Visual Basic, Javascript, Jscript, VBscript, Java, C#, C++, or anything other than C to write your Internet applications. > The balance is a delicate problem. But I'm sure that if there is a solution that is technically sound from a protocol perspective, then there will be a way to implemented in a sufficiently secure way for many usages. IF (there is a solution AND that solution is technically sound AND that solution fits into the TLS layer) THEN (it may be implemented). I cannot see it occurring, though. > As to the security discussion earlier, a very common way to eliminate the insecure DMZ is to publish the web server from a secure front end firewall holding and/or controlling the TLS keys. Unless you can hack that firewall you won't get to the keys or the server app side of the information flow. In any case, just because there is a way to implement a solution badly, does not mean that there is no good way to do it. "a secure front end firewall holding and/or controlling the TLS keys"... ...you've just defined "DMZ". Let's look at this from the viewpoint of "how can you prove that the firewall is secure, and has no available attacks against it other than DoS?" Or, better yet, let's look at this from the viewpoint of "how can I prove that my firewall is more secure than IIS?" > Stefan Santesson > Senior Program Manager > Windows Security, Standards ...and as an aside, it's this type of tunnel vision and complete idiocy which has earned Microsoft, quite rightly, the derision of security professionals. NONE of the proposed attacks have been addressed, and these example attacks have all been "off the cuff" examples. It is axiomatic that we're not thinking of all possible attacks, we're just bringing up the barest scratches of things that make this proposal completely impossible. Your suggestion of "secure firewall that controls the keys" is laughable at best and dangerous at worst -- the entire point of a firewall is to have a layer that provides no other function than to protect what is behind it. And even then, what is behind the firewall can be attacked and subverted. It merely limits the attack vectors; a firewall does not make attacks impossible. -Kyle H (yes, I know this is a relatively incendiary missive. I realize that IIS's security, and the security of the underlying operating system, have increased exponentially since Windows NT 4. I realize that Microsoft has made great strides toward reducing attack vectors. But I also realize that if attack vectors aren't nipped in the bud, they WILL be implemented, and they WILL cause problems for millions of users, with monetary outlay in the trillions of dollars before they're fixed. It is this which drives me to come down so hard on someone who holds an office which cannot afford to make these kind of mistakes.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 13:57:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uFe-0004l6-TE; Fri, 05 Jan 2007 13:57:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uFe-0004kw-4A for tls@ietf.org; Fri, 05 Jan 2007 13:57:14 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2uFc-0004GF-MP for tls@ietf.org; Fri, 05 Jan 2007 13:57:13 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id TAA10731; Fri, 5 Jan 2007 19:57:02 +0100 (MEZ) From: Martin Rex Message-Id: <200701051857.TAA22968@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: stefans@microsoft.com (Stefan Santesson) Date: Fri, 5 Jan 2007 19:57:02 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 5, 7 05:34:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > > I don't think this discussion is fair to the proposal, > but in a way it is what I expected to see when bringing > the concept of "evidence" to a TLS group. > > If we leave the concept of evidence out of scope and leave > it to the lawyers to worry about, is there any technical merits? > > There is one that I think we should consider. > If a client or a server want to ask its opponent > to sign a portion of data, is there any alternative > solutions that would work cross platforms. Of course there are, and have been in active and successful use for more than a year. They're at least as portable as the TLS implementation itself. > > PKCS#7/CMS or XML digsig is not an answer as it only provides > signature format, it does not deal with the request and response logic. You're kidding. You wouldn't know how to implement a function in an application UI that requests a signed Document (PDF,CMS,XMLsig) from the backend? In the HTML-world of the Internet this thing is called Hyperlink/URL. When Kerberos5-PKINIT was polluted ("enriched") with CMS and OCSP stuff you didn't seem to have a problem, and there is a proposal to ram Kerberos/GSS-API into TLS, so it is a total mystery to me why you suddenly try to make a problem out of CMS. The big advantage with this approach is that you don't need any additional APIs in order to retrieve TLS evidence from deep down, no new APIs to perform verification of the signature, it works perfectly fine with the installed base of middleware and client-software and best of all, you don't need thousands of case-specific custom software to make sense and visualize the raw network data of a TLS Evidence capture. > > Going higher up closer to the application requires standardization of > solutions based on vendor specific interpretation languages such as > Java or .NET. If that was anywhere as difficult as you think, then we wouldn't have PDFs or SWFs. Since right now, and for some considerable time to come, frontend/client- signing will still be rare and it is a total non-issue for the backend/server-signing. > > The balance is a delicate problem. But I'm sure that if there is a > solution that is technically sound from a protocol perspective, > then there will be a way to implemented in a sufficiently secure > way for many usages. TLS Evidence doesn't fit into the TLS architecture AT ALL, and there is an irresponsibly huge hazard that apps will use it all the wrong fashion and end users will be hopelessly confused about whether a TLS popup is about online authentication or a digital signature, so that a large number of applications will get it totally wrong. It is about a good idea as using pure liquide nitroglycerine. Responsible security engineers should stay away from this as far as they can. Our standards should not only be secure, but also fairly safe to use. > > As to the security discussion earlier, a very common way to > eliminate the insecure DMZ is to publish the web server from > a secure front end firewall holding and/or controlling the TLS keys. > Unless you can hack that firewall you won't get to the keys or > the server app side of the information flow. In any case, just > because there is a way to implement a solution badly, does not > mean that there is no good way to do it. Get real. The only reason that we have DMZs is that "businesses" insist on running feature-bloated, bug-ridden applications on the public internet which will have serious vulnerabilities found and published on a weekly, if not daily basis for decades to come. It really doesn't matter which application vendor you pick, all of them are affected, just that some of them are more attractive targets than others, have more vulernabilities published on a regular basis and therefore pose a higher risk for their operators of successful hacks/break-ins. DMZs are used to host the machines and "frontends" of web-shops, as a first line of defense, and they are supposed to filter and pre-process requests&data before submitting it for processing to a backend system on the internal network which hosts the vital company data. By closely monitoring the traffic within the DMZ and between the app/proxy in the DMZ and the backend system, you have significantly higher chances to notice and stop attackers from reaching your vital backend system. This approach works remarkably well, and it is being done that way for more than a decade now. I find it quite distracting that everytime that I show obvious vulnerabilities an a proposed application scenario making use of TLS Evidence that someone says: Oh, that is obvious fraud-- we don't worry about that, we can give it to the police and sue... Sorry, but that is the stupid reaction from a markedroid, definitely not from a security-experienced engineer. A good design doesn't have such vulnerabilities. Substituting security engineering and good design with evidence collecting for law enforcement agency and passing on the scapegoat to them is the most stupid approach to security that I've ever heard in a working group of the IETF security area. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 14:39:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uuR-0002RN-Hq; Fri, 05 Jan 2007 14:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uuQ-0002RH-2W for tls@ietf.org; Fri, 05 Jan 2007 14:39:22 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2uuN-0007S0-K6 for tls@ietf.org; Fri, 05 Jan 2007 14:39:22 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 75EE782D7; Fri, 5 Jan 2007 13:39:18 -0600 (CST) From: "Mark Brown" To: "'Kyle Hamilton'" , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Fri, 5 Jan 2007 13:40:51 -0600 Message-ID: <009301c73101$688feea0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6b9359640701041002n3e61bd4fx7a3caa0db891c824@mail.gmail.com> Thread-Index: AccwKorfGtDw16g2QIWbP9ZojivNUwA0UFiw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Kyle, You bring up at least two good points: 1) Aren't all keys/secrets known and potentially leaked by the sysadmin who makes them? 2) If the attacker compromises the keys, he can further the attack by setting up a fraudulent web site, with all the trimmings. Was I too quick to say, approximately, that TLS Evidence can deal with the (catastrophic!) event of both keys being compromised on the server (the TLS authentication key and the TLS Evidence signing key, considered as separate even if they could be the same)? I'm not convinced yet. 1) One good method for handling keys is to use a FIPS 140 hardware crypto module. Not just for algorithm acceleration, but specifically to generate and store keys, especially keypairs. The design for good key secrecy using a FIPS 140 device is to generate the keypair on the device and then sign the PKC request using the FIPS box. Then all subsequent signatures should be performed by the FIPS box. The goal is to never have a human know the secret key. This is compatible and recommendable for both TLS implementations and with the EAL6 separation kernel protection profile. So, no, the sysadmin doesn't always know nor have the ability to compromise the keys. Just follow best practices, i.e., use FIPS 140 hardware crypto well. 2) If both private keys are stored in the TLS implementation, and the attacker compromises both (here we pretty much assume that FIPS 140 hardware is not in use...), how effectively can he set up a rival web shop and leverage these keys to commit fraud? First, he's got DNS to deal with. After all, the PKC bound to the stolen key is bound to a DNS name. So browsers that attend the fraudulent site have to deal with the name mismatch between the cert and the URL. Let's say the browser's user blows off the warning and proceeds. Let's say the user sends in his/her credit card number etc. to the fraudulent site to make a payment. Let's say that the user actually got to the fraudulent site in the first place (phishing implied? Hack the links on the website?). Next, the TLS Evidence (assuming the minimum, say that it's turned on only for the POST of the final page) will show the URL and domain name used. That's in the application data. It will also show the certs used by the TLS server, that's in the TLS handshake & TLS Evidence data. TLS Evidence will show the mismatch here. Hijacking DNS is an option for the attacker. However, it's kinda slow, and it definitely rings the front doorbell at the organization that lost its keys and identity. Most organizations start contacting the ISP that is hosting the attacker at this point...FBI is another place to go...next it's a public announcement (unless you're in CA, in which case you'd announce immediately). Finally, the attacker has to cash the check, so to speak. Perhaps they just happen to have an account with a payment processor -- but they know the browser is holding evidence to their fraud. Perhaps they just want the credit card number & data. Maybe they plan to sell the info on the black market, or plan to make fraudulent card-not-present purchases. Even when granted all these assumptions for bad things to happen in the attacker's favor, it's a catastrophe yes, but it doesn't seem like the TLS Evidence either causes it or exacerbates it. In the end, the big worry is that the browser's user gave out his credit card number to an attacker. I think less-immediate actions on the user's part like making promises to the attacker don't pose much risk. The attacker can't hold the victim to the promises, not in court. The TLS Evidence actually proves the fraud, so it's not an accomplice. I think the attacker would be better off to turn off TLS Evidence and not even use this stolen key -- it can only hurt him. I still think that in comparison to a stolen TLS authentication key, a stolen TLS Evidence key is relatively harmless. In this kind of failure analysis (catastrophic key compromise), failing safe is about the best you can hope for. And I still think that keeping private keys exclusively on FIPS 140 hardware, or an EAL6 box, is a "best practices" way to avoid a lot of this. --mark > -----Original Message----- > From: Kyle Hamilton [mailto:aerowolf@gmail.com] > Sent: Thursday, January 04, 2007 12:03 PM > To: Mark Brown > Cc: martin.rex@sap.com; tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 > > On 1/4/07, Mark Brown wrote: > > > > Why? Because no one can generate TLS Evidence by compromising only the > > server's private keys. TLS EvidenceResponse structures are only valid > after > > both TLS client and TLS server have signed them. So for your scenario > to > > generate valid TLS Evidence you need the attacker to have compromised > the > > TLS server's authentication key and evidence key (they may be one and > the > > same though) and to have possession of the client's authentication key > and > > evidence key (they may be one and the same). This is not very feasible > > unless the attacker is the client. > > Isn't the entire point of an attack to harm the attacked? Motives > differ for attacks. The motives for attacks help describe/define what > attack is going to be carried out, and how. > > As an example, let's look at the "disgruntled employee" concept. > Sysadmin, disgruntled, has possession of the traffic and > signature-evidence keys, as he's responsible for making sure they get > into the correct place and are used in the correct manner. > > Owner or CFO or whathaveyou overlook this during employment/contract > termination. (Which is ASTOUNDINGLY easy to do.) > > Bingo, you suddenly have an attack against your business's legal > existence. > > > The attacker knows that just about anyone could check the TLS Evidence > > later. So the attacker needs to make some hard choices. Should the > > attacker get the dummy client PKC signed by a CA? Should the dummy > client > > PKC be signed by a CA that the TLS server trusts -- perhaps a CA that > > charges money for its PKCs, or perhaps a CA operated by the TLS server's > > organization? Perhaps the app server shows the last 4 digits of a > credit > > card number used to pay for the ticket on all real receipts -- should > the > > attacker use a real credit card number in the app data sent in the lab? > Now > > that credit card info is part of the TLS Evidence record. Or perhaps > the > > app server requires the buyer to send in his/her name to be printed on > the > > ticket receipt -- should the attacker use a real name? Etc. > > Should the attacker put an alternate server up, make it look like the > real thing, be authenticable as it... and let others connect to it > without realization that it's fake? > > > The attacker would have to be pretty bold to use a PKC with his real > name > > and/or embed a real credit card number into the app data signed by TLS > > Evidence. If a credit card number was used, a suspicious third party > could > > check to see if the charge actually went through. In a dispute, a third > > party might ask for secondary identification -- show me the credit card, > > show me your driver's license -- if forgery was suspected (the attacker > did > > grab both private keys from the TLS server by force...). > > Or, be bold enough to let others do it. Every one of the transactions > is individually actionable, and that can cripple a business with legal > fees. > > > On the other hand, you could buy a server certified at EAL6+ to do the > TLS > > and TLS Evidence for you, and that would make the foregoing discussion > moot > > by today's standards. Key compromise of an EAL6+ box is supposed to be > > pretty hard to do. > > ...except by people who have access regardless. > > > In any case, TLS Evidence makes no guarantees about the law / legality, > or > > that it prevents crime, etc. What it does is to use cryptography to > make > > forgery more difficult. This could be useful to applications. > > This is not something that can be solved at the network layer. It's > an application issue, and needs to be dealt with as such. > > -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 16:10:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wKc-0006Lt-5z; Fri, 05 Jan 2007 16:10:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wKa-0006Ln-RO for tls@ietf.org; Fri, 05 Jan 2007 16:10:28 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2wKZ-0007TF-Bq for tls@ietf.org; Fri, 05 Jan 2007 16:10:28 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA03181; Fri, 5 Jan 2007 22:10:12 +0100 (MEZ) From: Martin Rex Message-Id: <200701052110.WAA24872@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: stefans@microsoft.com (Stefan Santesson) Date: Fri, 5 Jan 2007 22:10:12 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 5, 7 05:34:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > > I don't think this discussion is fair to the proposal, but in a way it is > what I expected to see when bringing the concept of "evidence" > to a TLS group. > > If we leave the concept of evidence out of scope and leave it > to the lawyers to worry about, is there any technical merits? I do remember a funny statement, some along the lines: IBM's Microchannel is actually a 48-bit bus, which is why it is so expensive. 16 of those 48-bits are entirely reserved for lawyers, only 32-bits are available for the user. I have a serious problem seeing a technology promoted in the IETF security area whoose only purpose is to provide business opportunities to lawyers. What the public actually expects from us security experts is that we design protocols that are reliably safe and secure so that the number of occasions where users of our technology need to involve lawyers and courts go WAY DOWN. If we do not raise the unemployment rate among lawyers, then we're probably not doing our job in an adequate fashion. If one needs cleartext network traces of what goes in TLS and what comes out TLS, that can easily be done today (in fact, an application architecture which can not do that today is seriously broken-- it is impossible to provide REAL support for larger mission-critical application software without capabilities to trace at various protocol levels and API/component level), and the crap with the digital signatures is entirely unnecessary for technical analysis. If there are no real benefits in technical and security terms in a proposal, then you're just wasting a lot of peoples time in this forum. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 17:56:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xyk-0000lw-Dt; Fri, 05 Jan 2007 17:56:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xyj-0000lr-5U for tls@ietf.org; Fri, 05 Jan 2007 17:56:01 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2xyh-00013M-6J for tls@ietf.org; Fri, 05 Jan 2007 17:56:00 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 4EB13821F; Fri, 5 Jan 2007 16:55:56 -0600 (CST) From: "Mark Brown" To: "'EKR'" Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Fri, 5 Jan 2007 16:57:29 -0600 Message-ID: <009d01c7311c$e0a4cad0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <86vejn3eid.fsf@raman.networkresonance.com> Thread-Index: AccvioQB1hPTuyKITZekzT/Ow2WodQBidWpg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, I meant to say the rule is this: whatever app data you send, you MUST chase it with EvidenceRequest. So with this rule, server MUST expect EvidenceRequest-1 to be paired with ApplicationData-1. This rule is in effect for the entire TLS session including any resumes. > > Since I've run this example while dropping alerts, no start1, etc. are > > required and all application data will generate evidence until the > session > > is terminated. If alerts are dropped, then a fairly "safe" rule for > > evidence generation is to require that every time client or server dumps > a > > stream of application data to TLS records and to the wire (a single TLS > > write call by the app) an EvidenceRequest also be created and sent. > > Yes, but how does the *app* know that? App doesn't need to know. App can ignore all Evidence- messages so long as some component somewhere is storing them. If app needs to store them, app still doesn't need to be aware of the protocol rules. As far as the app is concerned, there's either app data (and Evidence- if it wants to fetch it) or there isn't. IF the TLS Evidence rules required that the TLS session be shut down, then app will discover that the session is terminated on next read or write attempt. The new api here is to allow apps to getLastEvidence(). If they call this in the middle of the session, or after the session closes or abends, the semantics are the same: null, or the last Evidence- structure sent/received. IF the app never calls getLastEvidence, that's Ok too as far as the TLS layer is concerned -- maybe a wiretap on the TLS session is the preferred method of persisting the TLS Evidence. > > > > The TLS > > layer simply lets the app layer set the pace in this no-alerts proposal. > > Since I'm provisionally dropping alerts here, I think it's best to NOT > reset > > the TLS Evidence application_data hashes any time during the session -- > just > > let them accumulate across all Evidence- messages for the session. My > > example of this is shown below: > > > > ApplicationData-1 --------> [Client's instructions] > > EvidenceRequest-1 --------> > > <-------- EvidenceResponse-1 > > [Server's response] <-------- ApplicationData-2 > > But there's a race condition here. The server doesn't know that > an EvidenceRequest-1 message is coming, so how does it know > to wait for it before executing whatever transaction the client > requested? Remember that TLS is a stream protocol, so the only > boundaries are at the higher layer. See above, the server has knowledge that: throughout this entire TLS Session EvidenceRequests MUST follow ApplicationData "immediately". If client gets cold feet about the transaction it would be more polite to send an alert to close the session. But under these circumstances the client is not likely to be DOS'ing the server -- server has authenticated client. > If the server wants to follow the (reasonable) policy of not > performing any actions until after he's received signed instructions > from the client, then he has to block waiting for the client to > generate a signature. At minimum this requires interaction with the app > because (again) the TLS stack doesn't know. Moreover, without > some external agreement about how often these are generated, > you can get a deadlock. Now, the server could certainly ask for > a signature by sending his own Evidence-Request, but now you're > requiring app interaction. I think there's ways to address this challenge. My solution is ok not great. Have the TLS server hold on to the last app data TLS record until another app data or an EvidenceRequest arrives. Don't notify, or have TLS keep it locked away from the app, etc., depending on the style of integration with the server app. Now if the EvidenceRequest never arrives presume it's because the line got cut. Notify the server app of the socket failure without delivering the last app data record. Now the server app faces the same problem that he faces whether he uses TLS, TLS Evidence or just a socket, so the server app already needs to be able to deal with that problem. On the other hand, if EvidenceRequest arrives and there's a crypto failure in it, TLS server should presume it's an attack. There's no valid reason for an error I can think of. This is not a shrug and forget about it situation. Blacklist or revoke the client PKC, roll back the app transaction with a severe error, fire up a pager, etc. I think what I'm saying is that in a mutually authenticated, evidence-generating situation it is correct to be strict on failures and lenient on no-shows. Both parties are very interested in this transaction, and they will understand if, for the sake of security, there's some inefficiencies incurred under rainy-day circumstances. I also think that DOS attacks are less likely under mutual authentication circumstances; if they occur, then you know who perpetrated them (at least which private key(s) did). > > Threats I've considered include: client or server "hangs up" at an > opportune > > moment in the exchange, one sends garbage, one sends something > unexpected in > > the app data. I think all of these threats pose little risk to the > parties > > because of two facts. > > > > 1) before either party gets their EvidenceResponse, they can walk away > and > > claim "it didn't happen." > > But transaction rollbacks are expensive and complicated. It's much > better to simply not perform the transaction if the counterparty > hasn't authenticated. Moreover, in this system you *need* to > treat a failed evidence handshake (e.g., due to network failures) > as an attack and execute a transaction rollback. With ordinary > signed messages this isn't true since a network failure just > causes the counterparty not to get their receipt. > > -Ekr Yes, it really would be a pain to do transaction rollbacks. But the premise I want to start with is that the cost of a tx rollback has already been determined at design time to be less than the cost of getting the tx or its evidence wrong. I don't want to try to pretend that tacking on TLS Evidence won't cost you. It will. But in some cases the cost of adding this kind of security (forgery resistance) is outweighed by the benefits. It's just another security trade-off. What we're talking about is failure and attack cases. I want TLS Evidence to fail secure whether the line is cut or an attack is underway. But I think since the mutual authentication has completed already it's overkill to require TLS Evidence to fail secure AND fail efficiently (i.e. avoid DOS and rollbacks). Because server knows who is on the other end, server gives a little more latitude, takes a little more risk of lost time. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 18:14:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yG8-00078Y-EG; Fri, 05 Jan 2007 18:14:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yG7-00078T-Dd for tls@ietf.org; Fri, 05 Jan 2007 18:13:59 -0500 Received: from simmts5-srv.bellnexxia.net ([206.47.199.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2yG5-0005SV-3e for tls@ietf.org; Fri, 05 Jan 2007 18:13:59 -0500 Received: from pbo8f8e10aowa ([65.94.175.125]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070105231354.GHDW4412.simmts5-srv.bellnexxia.net@pbo8f8e10aowa>; Fri, 5 Jan 2007 18:13:54 -0500 Message-ID: <001801c7311f$60eeabf0$7daf5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: , "Mark Brown" References: <200701042049.VAA04275@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Fri, 5 Jan 2007 18:15:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org see inserted: ----- Original Message ----- From: "Martin Rex" To: "Mark Brown" Cc: Sent: Thursday, January 04, 2007 3:49 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > Mark Brown wrote: > > > > Isn't this attack possible with today's web sales? I mean, once you give > > your credit card to anyone, can't they ring you out at any price they want? > > You don't need a website or TLS to do this attack. You can do this on the > > phone or via mail order. > > > > So in the case of TLS Evidence, you both have a record of (1,499,999.-) > > instead of what the buyer thought, (99,999.-). So what? In both cases the > > buyer cancels the order. You don't need TLS Evidence to cancel...with > > either the merchant or by contacting your credit card issuer. > > No I am confused. > > Since you just completely disclaimed the usefulness of TLS evidence > for just about every business application, what's left? I have more "disclaimers": at least in US and at least one big b2b exchange said that they have a simple non-repudiation practice: they make customers (buyers and sellers) to sign the agreement that stipulates that whatever is the record of a transaction in the exchange database that holds as the non-repudable record. (the name witheld due to the NDA). So they have no need for even application level non-repudiation. Also consumers in US have Reg A that allows them to repudiate transactions even if a business has evidence. -Omirjan > > I don't see anything besides law enforcement, and I have serious > problems in making cleartext escrow plus digital signing of > the communication an IETF working group item. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 20:26:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30Jw-0002fG-Fn; Fri, 05 Jan 2007 20:26:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30Ju-0002f7-Ku for tls@ietf.org; Fri, 05 Jan 2007 20:26:02 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H30Jt-0002bQ-3x for tls@ietf.org; Fri, 05 Jan 2007 20:26:02 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 30F211E8C5D; Fri, 5 Jan 2007 17:25:58 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <009d01c7311c$e0a4cad0$6801a8c0@rps.local> From: Eric Rescorla Date: Fri, 05 Jan 2007 17:25:58 -0800 In-Reply-To: <009d01c7311c$e0a4cad0$6801a8c0@rps.local> (Mark Brown's message of "Fri, 5 Jan 2007 16:57:29 -0600") Message-ID: <86odpdaqu1.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: > Eric, > > I meant to say the rule is this: whatever app data you send, you MUST chase > it with EvidenceRequest. So with this rule, server MUST expect > EvidenceRequest-1 to be paired with ApplicationData-1. This rule is in > effect for the entire TLS session including any resumes. 1. I don't understand what you mean by "whatever app data you send". Do you mean after any application write to TLS? Any record? Recall that TLS is a stream protocol. In the former case, how does the receiver enforce this rule? In the latter case, you're signing every record. 2. It seems to me that you've just required that every single TLS record (or at least short runs of records) be signed (plus a second signature by the receiver). Have you considered the performance and bandwidth issues associated here? > If app needs to store them, app > still doesn't need to be aware of the protocol rules. As far as the app is > concerned, there's either app data (and Evidence- if it wants to fetch it) > or there isn't. IF the TLS Evidence rules required that the TLS session be > shut down, then app will discover that the session is terminated on next > read or write attempt. I don't understand what this means. >> If the server wants to follow the (reasonable) policy of not >> performing any actions until after he's received signed instructions >> from the client, then he has to block waiting for the client to >> generate a signature. At minimum this requires interaction with the app >> because (again) the TLS stack doesn't know. Moreover, without >> some external agreement about how often these are generated, >> you can get a deadlock. Now, the server could certainly ask for >> a signature by sending his own Evidence-Request, but now you're >> requiring app interaction. > > I think there's ways to address this challenge. My solution is ok not > great. Have the TLS server hold on to the last app data TLS record until > another app data or an EvidenceRequest arrives. Don't notify, or have TLS > keep it locked away from the app, etc., depending on the style of > integration with the server app. Now if the EvidenceRequest never arrives > presume it's because the line got cut. Notify the server app of the socket > failure without delivering the last app data record. Now the server app > faces the same problem that he faces whether he uses TLS, TLS Evidence or > just a socket, so the server app already needs to be able to deal with that > problem. I think "not great" is quite an understatement here. You've just required that every TLS record write requires *two* signatures, one from the sender and one from the receiver. This includes record read/writes which the application doesn't even care about having evidence for. Your typical brokerage transaction requires 10s if not hundreds of separate HTTP fetches, each of which requires one or more record in each direction. Doing 25 digital signatures for every transaction is an enormous load on the server. By contrast, message-oriented solutions are inherently more efficient since you can sign at the message rather than the record level and moreover you can sign selectively. Yes, I appreciate you can use alerts, etc. to sign selective portions of the stream, but now you're getting into the case of application interaction again. >> But transaction rollbacks are expensive and complicated. It's much >> better to simply not perform the transaction if the counterparty >> hasn't authenticated. Moreover, in this system you *need* to >> treat a failed evidence handshake (e.g., due to network failures) >> as an attack and execute a transaction rollback. With ordinary >> signed messages this isn't true since a network failure just >> causes the counterparty not to get their receipt. >> >> -Ekr > > Yes, it really would be a pain to do transaction rollbacks. But the premise > I want to start with is that the cost of a tx rollback has already been > determined at design time to be less than the cost of getting the tx or its > evidence wrong. Sure, but those aren't the only two design choices. In particular, message-oriented signature schemes don't have this problem. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 21:08:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30yF-00020C-ML; Fri, 05 Jan 2007 21:07:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30yE-000207-A9 for tls@ietf.org; Fri, 05 Jan 2007 21:07:42 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H30yC-0000ei-Uw for tls@ietf.org; Fri, 05 Jan 2007 21:07:42 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id DAA21658; Sat, 6 Jan 2007 03:07:34 +0100 (MEZ) From: Martin Rex Message-Id: <200701060207.DAA00185@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Sat, 6 Jan 2007 03:07:33 +0100 (MET) In-Reply-To: <009d01c7311c$e0a4cad0$6801a8c0@rps.local> from "Mark Brown" at Jan 5, 7 04:57:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > > > > Yes, but how does the *app* know that? > > App doesn't need to know. App can ignore all Evidence- messages so long as > some component somewhere is storing them. > ... maybe a wiretap on the TLS session is the preferred > method of persisting the TLS Evidence. It's time to shut down the discussion in this forum for procedural violations of the IETF Danvers Doctrine. The IETF will NOT put wire-tapping hooks into its protocols. -Martin > > I think what I'm saying is that in a mutually authenticated, > evidence-generating situation it is correct to be strict on failures and > lenient on no-shows. Both parties are very interested in this transaction, > and they will understand if, for the sake of security, there's some > inefficiencies incurred under rainy-day circumstances. First you say that lots of applications don't actually care about (TLS) evidence, its mainly for a wire-tapping third-party, then you suddenly say that those applications do want communication failures when there is a problem with the TLS Evidence (which the most apps don't care about), and then you go even further and claim that those majority of dont-know-or-care-about-tls-evidence will happily pay for the significant extra overhead in processing time incured by a service they never asked for in the first place. This is ridiculous. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 21:31:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Kw-0002dq-46; Fri, 05 Jan 2007 21:31:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Ku-0002dg-NW for tls@ietf.org; Fri, 05 Jan 2007 21:31:08 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31Kt-0005jy-GZ for tls@ietf.org; Fri, 05 Jan 2007 21:31:08 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id E4355810D; Fri, 5 Jan 2007 20:31:02 -0600 (CST) From: "Mark Brown" To: "'EKR'" Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Fri, 5 Jan 2007 20:32:36 -0600 Message-ID: <00aa01c7313a$ed9c34d0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <86odpdaqu1.fsf@raman.networkresonance.com> Thread-Index: AccxMZ9amUnDBS33SFmiJFoII9hQgQAAZqFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, > I think "not great" is quite an understatement here. You've just > required that every TLS record write requires *two* signatures, > one from the sender and one from the receiver. This includes > record read/writes which the application doesn't even care > about having evidence for. Your typical brokerage transaction > requires 10s if not hundreds of separate HTTP fetches, each > of which requires one or more record in each direction. Doing > 25 digital signatures for every transaction is an enormous > load on the server. Turn on TLS Evidence only for one POST, skip the GETs. There's typically one important POST per transaction, the one before the print-this-page-for-your-records response. That's the page the user typically prints for evidence of the transaction, despite its failings. It doesn't make sense to create TLS Evidence for every fetch. What would be the point of being able to show for posterity that some browser downloaded 20 gifs, a css file and two javascript files? None. Regarding performance estimates, whether you use a FIPS 140 accelerator or not, the cost of two digital signatures and the extra TLS Evidence messages is less than the 20+ round trips made to load the page, even if the client is using multiple connections. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 21:32:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Lc-0002vR-Ik; Fri, 05 Jan 2007 21:31:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31La-0002vH-P3 for tls@ietf.org; Fri, 05 Jan 2007 21:31:50 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31LZ-0005ub-IA for tls@ietf.org; Fri, 05 Jan 2007 21:31:50 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 1197A810F for ; Fri, 5 Jan 2007 20:31:49 -0600 (CST) From: "Mark Brown" To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Fri, 5 Jan 2007 20:33:22 -0600 Message-ID: <00ab01c7313b$091326b0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccxMZ9amUnDBS33SFmiJFoII9hQgQAAZqFgAAHxn5A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, > I think "not great" is quite an understatement here. You've just > required that every TLS record write requires *two* signatures, > one from the sender and one from the receiver. This includes > record read/writes which the application doesn't even care > about having evidence for. Your typical brokerage transaction > requires 10s if not hundreds of separate HTTP fetches, each > of which requires one or more record in each direction. Doing > 25 digital signatures for every transaction is an enormous > load on the server. Turn on TLS Evidence only for one POST, skip the GETs. There's typically one important POST per transaction, the one before the print-this-page-for-your-records response. That's the page the user typically prints for evidence of the transaction, despite its failings. It doesn't make sense to create TLS Evidence for every fetch. What would be the point of being able to show for posterity that some browser downloaded 20 gifs, a css file and two javascript files? None. Regarding performance estimates, whether you use a FIPS 140 accelerator or not, the cost of two digital signatures and the extra TLS Evidence messages is less than the 20+ round trips made to load the page, even if the client is using multiple connections. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 05 21:46:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Zs-0008C3-Ja; Fri, 05 Jan 2007 21:46:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Zr-0008Bu-Ej for tls@ietf.org; Fri, 05 Jan 2007 21:46:35 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31Zq-0008WN-2p for tls@ietf.org; Fri, 05 Jan 2007 21:46:35 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2D1011E8C5D; Fri, 5 Jan 2007 18:46:33 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <00aa01c7313a$ed9c34d0$6801a8c0@rps.local> From: Eric Rescorla Date: Fri, 05 Jan 2007 18:46:33 -0800 In-Reply-To: <00aa01c7313a$ed9c34d0$6801a8c0@rps.local> (Mark Brown's message of "Fri, 5 Jan 2007 20:32:36 -0600") Message-ID: <86mz4wan3q.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: > Eric, > >> I think "not great" is quite an understatement here. You've just >> required that every TLS record write requires *two* signatures, >> one from the sender and one from the receiver. This includes >> record read/writes which the application doesn't even care >> about having evidence for. Your typical brokerage transaction >> requires 10s if not hundreds of separate HTTP fetches, each >> of which requires one or more record in each direction. Doing >> 25 digital signatures for every transaction is an enormous >> load on the server. > > Turn on TLS Evidence only for one POST, skip the GETs. There's typically > one important POST per transaction, the one before the > print-this-page-for-your-records response. That's the page the user > typically prints for evidence of the transaction, despite its failings. Yes, but *now* you're in the business of having the application require tight control of when signatures are created and when they're available, which brings us back to the situation I was complaining about in my initial review, where this isn't just automatic, it requires esxtensively modifying the app, plus the race condition/lockstep issues I raised in my original review. > It doesn't make sense to create TLS Evidence for every fetch. What would be > the point of being able to show for posterity that some browser downloaded > 20 gifs, a css file and two javascript files? None. I totally agree with that. That's the virtue of a message signing scheme like S/MIME. > Regarding performance estimates, whether you use a FIPS 140 accelerator or > not, the cost of two digital signatures and the extra TLS Evidence messages > is less than the 20+ round trips made to load the page, even if the client > is using multiple connections. It depends what you're measuring, latency or CPU time. The dominant CPU cost of SSL/TLS is the RSA key exchange (which is commensurate cost with signing, of course)[0]. Providing evidence (independent signatures) for a single request/response pair entails that the server do two additional signatures (one in response to the Evidence-Request for the client request and one in its Evidence-Request for the response). This substantially increases the server load quite a bit beyond the symmetric crypto cost. And of course there's no guarantee that a request or response goes in a single TLS record, which may or may not be the case. -Ekr [0] C. Coarfa, P. Druschel, and D. Wallach. Performance Analysis of TLS Web Servers. In Proceedings of NDSS '02, 2002. 0 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 08:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ut0-0001da-TU; Mon, 08 Jan 2007 08:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3usz-0001b1-60 for tls@ietf.org; Mon, 08 Jan 2007 08:50:01 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3usx-00078W-Po for tls@ietf.org; Mon, 08 Jan 2007 08:50:01 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id OAA21495; Mon, 8 Jan 2007 14:49:53 +0100 (MEZ) From: Martin Rex Message-Id: <200701081348.OAA27556@uw1048.wdf.sap.corp> To: tls@ietf.org Date: Mon, 8 Jan 2007 14:48:53 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [TLS] draft-housley-evidence-extns-00 worse than key escrow X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org What has become obvious from the disscussion so far is not only that the draft-housley-evidence-extns-00 is absolutely useless for purposes of creating receipts for internet online commerce, it's primary intention is to completely subvert the TLS protocol in order to provide a means for law enforcment agencies to collect evidence of thought-to-be private (tele)communications for direct use in court, in a quality that will make it difficult to impossible deny/repudiate. 10 years ago, we thought that mandatory key escrow would be the worst that could happen to computer security. This proposal is worse by a significant margin. The obvious drawback of key escrow is, that with the keys one can not only reveal the protected communication, but also trivially "fabricate" evidence, which would significantly impair/ruin the quality of "wire-tapped" communcations as (sole) evidence in court. With the TLS evidence approach, requiring EAL6+ crypto hardware and keystores on every telecommunication device and having them sign the entire raw communication, the wire-tapped can not only be used for intelligence purposes and further investigations leading to real evidence, it can be used directly as evidence against either or both of the unsuspecting and unconsenting communication peers. For the usage scenario that Mark is looking at, the communication peers are going to be an end user's telecommunications device on one side and some network operators phone switch on the other. I don't know whether he's thinking of VoiP or the next generation of mobile phones. So the key on the "users side" (plus a certificate by an government-authorized CA) would likely be a requirement for the device to access the phone switch, and it would first of all identify the device and communications from this device, rather than an actual user. There is no intention to notify or even ask for consent for a signed wire-tap evidence, of course. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 09:58:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vw3-0002BH-5r; Mon, 08 Jan 2007 09:57:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vw1-0002Ae-Ba for tls@ietf.org; Mon, 08 Jan 2007 09:57:13 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3vvv-0006gn-Ja for tls@ietf.org; Mon, 08 Jan 2007 09:57:13 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id A859B899B; Mon, 8 Jan 2007 08:57:01 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] draft-housley-evidence-extns-00 worse than key escrow Date: Mon, 8 Jan 2007 08:58:36 -0600 Message-ID: <00bb01c73335$79b2e940$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200701081348.OAA27556@uw1048.wdf.sap.corp> Thread-Index: AcczLFwX1mbFRcvIQMGs8EWwCzvmygAB1nIA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org These conclusions are unsound, the conjecture about my intentions is untrue, and some statements are plainly contradictory to the specifications of the Internet Draft. I'll respond in more detail on Wednesday. > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: Monday, January 08, 2007 7:49 AM > To: tls@ietf.org > Subject: [TLS] draft-housley-evidence-extns-00 worse than key escrow > > What has become obvious from the disscussion so far is not only > that the draft-housley-evidence-extns-00 is absolutely useless > for purposes of creating receipts for internet online commerce, > it's primary intention is to completely subvert the TLS protocol > in order to provide a means for law enforcment agencies to > collect evidence of thought-to-be private (tele)communications > for direct use in court, in a quality that will make it difficult > to impossible deny/repudiate. > > 10 years ago, we thought that mandatory key escrow would be the worst > that could happen to computer security. This proposal is worse by > a significant margin. > > The obvious drawback of key escrow is, that with the keys one can > not only reveal the protected communication, but also trivially > "fabricate" evidence, which would significantly impair/ruin the quality > of "wire-tapped" communcations as (sole) evidence in court. > > With the TLS evidence approach, requiring EAL6+ crypto hardware and > keystores on every telecommunication device and having them sign > the entire raw communication, the wire-tapped can not only be used > for intelligence purposes and further investigations leading to > real evidence, it can be used directly as evidence against either > or both of the unsuspecting and unconsenting communication peers. > > For the usage scenario that Mark is looking at, the communication > peers are going to be an end user's telecommunications device on > one side and some network operators phone switch on the other. > I don't know whether he's thinking of VoiP or the next generation > of mobile phones. > > So the key on the "users side" (plus a certificate by an > government-authorized CA) would likely be a requirement for the > device to access the phone switch, and it would first of all > identify the device and communications from this device, > rather than an actual user. There is no intention to notify or > even ask for consent for a signed wire-tap evidence, of course. > > > -Martin > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 11:20:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xDn-0007If-Ot; Mon, 08 Jan 2007 11:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xDm-0007EG-Jw for tls@ietf.org; Mon, 08 Jan 2007 11:19:38 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3xDi-0000IE-LS for tls@ietf.org; Mon, 08 Jan 2007 11:19:38 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l08GJVGs012006 for ; Mon, 8 Jan 2007 11:19:31 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 08 Jan 2007 11:19:31 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Jan 2007 11:19:30 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Mon, 8 Jan 2007 11:19:31 -0500 Message-ID: In-Reply-To: <200701052110.WAA24872@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Index: AccxDgjjJCOYCAePSPadD96kNDbLCgCKBI9A From: "Kemp, David P." To: X-OriginalArrivalTime: 08 Jan 2007 16:19:30.0845 (UTC) FILETIME=[C6BB84D0:01C73340] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14922003 X-TM-AS-Result: : Yes--11.469800-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDQ0?= =?us-ascii?B?OTYtNzA3NzYwLTcwMjEzMS03MDYxOTEtNzEwNDQyLTcwNjk1NS0x?= =?us-ascii?B?MjExNTUtMTIxNjI4LTcwMDE1MS03MDIxMTMtNzAxNzQxLTcwNDU2?= =?us-ascii?B?NC03MDMzNjYtNzA2ODkxLTcwMzk2NC03MDI3MTAtNzEwOTcwLTcw?= =?us-ascii?B?MjA1NC0xMzkwMDYtNzAwMDczLTcwODAyOS03MDE5NjAtNzA4Nzky?= =?us-ascii?B?LTcwNDMwMS03MDM4MjQtNzAyMTQ2LTEwNjU4MC03MDAwNzUtMTM5?= =?us-ascii?B?MDEwLTcwMTQ2MS03MDM3ODItMTg4MDE5LTcwMDg0My03MDcwNTAt?= =?us-ascii?B?NzAxNDM1LTE0ODA1MC0yMDA0MA==?= X-Spam-Score: 1.1 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The juxtaposition of these two statements, coming from the same source on the same day, is interesting. What is the difference between a "network trace" and a "wiretap"? An application architecture that stores trace data does not require modification (hooking) of the protocol. And a modification to the protocol to transmit digitally signed data changes neither the confidentiality properties of the protocol nor the existence of application architectures that store trace data. Note that: "the crap with the digital signatures is entirely unnecessary for technical analysis." is entirely correct. But Danvers is a non-sequitur. Ignoring lawyers, non-repudiation, and protocol analysis, the question remains: is there any benefit to providing data origin authentication at the TLS layer? In other words, assume the existence of an evaluated high assurance "TLS Appliance" fronting an application that is much more complex and dynamic and difficult to characterize from a security perspective. Is there any benefit to having the TLS box sign data instead of having the application sign data itself? I'm not convinced there is, but regardless, it would be better to focus the discussion on the relying party's ability to validate signatures for its own benefit rather than discuss taking those signatures to court. Dave -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Friday, January 05, 2007 4:10 PM If one needs cleartext network traces of what goes in TLS and what comes out TLS, that can easily be done today (in fact, an application architecture which can not do that today is seriously broken-- it is impossible to provide REAL support for larger mission-critical application software without capabilities to trace at various protocol levels and API/component level), and the crap with the digital signatures is entirely unnecessary for technical analysis. -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Friday, January 05, 2007 9:08 PM Mark Brown wrote: > App doesn't need to know. App can ignore all Evidence- messages > so long as some component somewhere is storing them. > ... maybe a wiretap on the TLS session is the preferred > method of persisting the TLS Evidence. It's time to shut down the discussion in this forum for procedural violations of the IETF Danvers Doctrine. The IETF will NOT put wire-tapping hooks into its protocols. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 11:50:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xgo-0004hN-7y; Mon, 08 Jan 2007 11:49:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xgm-0004hH-H4 for tls@ietf.org; Mon, 08 Jan 2007 11:49:36 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3xgk-0001fj-8H for tls@ietf.org; Mon, 08 Jan 2007 11:49:36 -0500 Received: (qmail 27240 invoked by uid 0); 8 Jan 2007 16:49:26 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 8 Jan 2007 16:49:26 -0000 Message-Id: <7.0.0.16.2.20070108114317.04081c38@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 08 Jan 2007 11:43:56 -0500 To: "Kemp, David P." , From: Russ Housley Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 In-Reply-To: References: <200701052110.WAA24872@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Thanks Dave. I appreciate your effort to get the group to focus on the question that is really being asked. Russ At 11:19 AM 1/8/2007, Kemp, David P. wrote: >The juxtaposition of these two statements, coming from >the same source on the same day, is interesting. > >What is the difference between a "network trace" >and a "wiretap"? An application architecture that >stores trace data does not require modification (hooking) >of the protocol. And a modification to the protocol >to transmit digitally signed data changes neither >the confidentiality properties of the protocol nor >the existence of application architectures that >store trace data. > >Note that: >"the crap with the digital signatures is entirely >unnecessary for technical analysis." >is entirely correct. But Danvers is a non-sequitur. > >Ignoring lawyers, non-repudiation, and protocol >analysis, the question remains: is there any benefit >to providing data origin authentication at the TLS >layer? In other words, assume the existence of an >evaluated high assurance "TLS Appliance" fronting an >application that is much more complex and dynamic >and difficult to characterize from a security >perspective. Is there any benefit to having the >TLS box sign data instead of having the application >sign data itself? I'm not convinced there is, >but regardless, it would be better to focus the >discussion on the relying party's ability to >validate signatures for its own benefit rather >than discuss taking those signatures to court. > >Dave > > >-----Original Message----- >From: Martin Rex [mailto:martin.rex@sap.com] >Sent: Friday, January 05, 2007 4:10 PM > >If one needs cleartext network traces of what goes in TLS and >what comes out TLS, that can easily be done today (in fact, >an application architecture which can not do that today is >seriously broken-- it is impossible to provide REAL support for >larger mission-critical application software without capabilities >to trace at various protocol levels and API/component level), >and the crap with the digital signatures is entirely unnecessary >for technical analysis. > >-----Original Message----- >From: Martin Rex [mailto:martin.rex@sap.com] >Sent: Friday, January 05, 2007 9:08 PM > >Mark Brown wrote: > > App doesn't need to know. App can ignore all Evidence- messages > > so long as some component somewhere is storing them. > > ... maybe a wiretap on the TLS session is the preferred > > method of persisting the TLS Evidence. > >It's time to shut down the discussion in this forum for >procedural violations of the IETF Danvers Doctrine. >The IETF will NOT put wire-tapping hooks into its protocols. > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 12:33:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3yMZ-0008Fx-CP; Mon, 08 Jan 2007 12:32:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3yMY-0008Fa-2k for tls@ietf.org; Mon, 08 Jan 2007 12:32:46 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3yMW-00005e-Pk for tls@ietf.org; Mon, 08 Jan 2007 12:32:46 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 44D1A1E8C5D; Mon, 8 Jan 2007 09:32:44 -0800 (PST) To: "Kemp, David P." Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: From: Eric Rescorla Date: Mon, 08 Jan 2007 09:32:44 -0800 In-Reply-To: (David P. Kemp's message of "Mon, 8 Jan 2007 11:19:31 -0500") Message-ID: <86lkkd5sqr.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Kemp, David P." writes: > Note that: > "the crap with the digital signatures is entirely > unnecessary for technical analysis." > is entirely correct. But Danvers is a non-sequitur. > > Ignoring lawyers, non-repudiation, and protocol > analysis, the question remains: is there any benefit > to providing data origin authentication at the TLS > layer? I don't think "data origin authentication" is the right term here, since TLS *does* provide data origin authentication. The client knows who he's talking to. What it doesn't provide is third party proof of data origin authentication and more importantly of message contents. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 12:59:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ylk-0003Ht-4l; Mon, 08 Jan 2007 12:58:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ylj-0003Hm-28 for tls@ietf.org; Mon, 08 Jan 2007 12:58:47 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3ylh-0000iV-FE for tls@ietf.org; Mon, 08 Jan 2007 12:58:47 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l08HwhGs019242 for ; Mon, 8 Jan 2007 12:58:43 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 08 Jan 2007 12:58:43 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Jan 2007 12:58:43 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Mon, 8 Jan 2007 12:58:42 -0500 Message-ID: In-Reply-To: <86lkkd5sqr.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Index: AcczSwipUJQI9rpCSIKVTZLLUOzNEAAAH/jA From: "Kemp, David P." To: X-OriginalArrivalTime: 08 Jan 2007 17:58:43.0300 (UTC) FILETIME=[A2AC1240:01C7334E] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14922003 X-TM-AS-Result: : Yes--1.660000-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDQ5?= =?us-ascii?B?ODAtNzAyMDQ0LTcwNjY0My03MDIxMTMtNzAxNTkwLTcwMTc0MS03?= =?us-ascii?B?MDg3OTItNzAwMjgxLTcwMTcxOS03MDEwODMtNzAwNDA1LTcwNTk1?= =?us-ascii?B?Ny03MDEyMDQtNzAxNTg4LTcwMzM3OC03MDE0NTUtNzA0MDQ5LTcw?= =?us-ascii?B?MDQ3Ni03MDU1MDgtNzAzMzcxLTcwMjA1NC0xMzkwMDYtNzAwMTM1?= =?us-ascii?B?LTcwMDA3My03MDE5NjAtNzAxMTc1LTEwNjIzMC03MDM3MzEtMTM5?= =?us-ascii?B?MDEwLTEyMTYyOC03MDAxNTEtMTIxMTU1LTEwNTcwMC03MDExODMt?= =?us-ascii?B?NzAxNDYxLTcwMDk1My0xNDgwNTAtMjAwNDA=?= X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Actually, I don't want to revive the NR-wars, but the DoD certificate policy uses the term "technical non-repudiation" to refer to "persistent data origin authentication" that can be validated outside the context of a session (a shared secret context), yet attempts to distance itself from what is visible at the HMI, the intent of the signer, the legal liability incurred, data retention periods, and all the rest of the stuff that goes with NR. If the Handbook of Applied Cryptography had defined TNR or PDOA, I would have used it, but alas it does not. What you said is (almost) what I meant -- integrity of message contents is a prerequisite for, and is thus implied by, data origin authentication Dave -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Monday, January 08, 2007 12:33 PM To: Kemp, David P. Cc: tls@ietf.org Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 "Kemp, David P." writes: > Note that: > "the crap with the digital signatures is entirely > unnecessary for technical analysis." > is entirely correct. But Danvers is a non-sequitur. > > Ignoring lawyers, non-repudiation, and protocol > analysis, the question remains: is there any benefit > to providing data origin authentication at the TLS > layer? I don't think "data origin authentication" is the right term here, since TLS *does* provide data origin authentication. The client knows who he's talking to. What it doesn't provide is third party proof of data origin authentication and more importantly of message contents. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 13:40:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zPm-0005Fu-P5; Mon, 08 Jan 2007 13:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zPl-0005CJ-B1 for tls@ietf.org; Mon, 08 Jan 2007 13:40:09 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zPj-0004Uc-Vm for tls@ietf.org; Mon, 08 Jan 2007 13:40:09 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA09973; Mon, 8 Jan 2007 19:39:55 +0100 (MEZ) From: Martin Rex Message-Id: <200701081839.TAA02191@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Mon, 8 Jan 2007 19:39:54 +0100 (MET) In-Reply-To: <006001c7305d$6d6b9f90$6801a8c0@rps.local> from "Mark Brown" at Jan 4, 7 06:07:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Ephemeral RSA? I hadn't thought about that. In Rescorla's book it seems to > be a tweak used to adapt to US export limits (512 bit RSA keys for export). Almost all of the code is already present in existing implementations in order to support the SSLv3 RSA_EXPORT key exchange methods with server certs using >512 bit RSA keys. The weakness in current SSL/TLS with the regular RSA ciphers is, that when you get your hands on the private key of the Server, then you can decrypt all archived encrypted sessions that were established with that key as well as passively attack all new sessions that are being established with that key. With temporary/ephemeral RSA keypairs, recovery of previous session is no longer possible after the server has replaced (and securely purged) the temporary keypar, and simple passive attacks don't work, either. An active MITM attack or access to the temporary keypair is required to attack the communication at the network level. When the servers longterm authentication keypair is also used directly for setting up the session keying material, it becomes a much more attractive target for brute force attacks, for key-stealing and for secret or non-consensual key-escrow. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 13:56:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zfA-0003wr-Ie; Mon, 08 Jan 2007 13:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zf8-0003wj-PM for tls@ietf.org; Mon, 08 Jan 2007 13:56:02 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3zf6-0007BX-Go for tls@ietf.org; Mon, 08 Jan 2007 13:56:02 -0500 Received: (qmail 8280 invoked by uid 0); 8 Jan 2007 18:55:51 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 8 Jan 2007 18:55:51 -0000 Message-Id: <7.0.0.16.2.20070108134610.040ccd00@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 08 Jan 2007 13:48:27 -0500 To: EKR From: Russ Housley Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 In-Reply-To: <86lkkd5sqr.fsf@raman.networkresonance.com> References: <86lkkd5sqr.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Right, it is persistent, which is not normally a requirement of authentication schemes. However, the point is to focus on the properties of the proposed mechanism and see if there is a community that would make use of them. Russ At 12:32 PM 1/8/2007, Eric Rescorla wrote: >"Kemp, David P." writes: > > Note that: > > "the crap with the digital signatures is entirely > > unnecessary for technical analysis." > > is entirely correct. But Danvers is a non-sequitur. > > > > Ignoring lawyers, non-repudiation, and protocol > > analysis, the question remains: is there any benefit > > to providing data origin authentication at the TLS > > layer? > >I don't think "data origin authentication" is the right term >here, since TLS *does* provide data origin authentication. The >client knows who he's talking to. What it doesn't provide is >third party proof of data origin authentication and more importantly >of message contents. > >-Ekr > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 14:29:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40Am-0001VN-Gk; Mon, 08 Jan 2007 14:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40Al-0001VB-8s for tls@ietf.org; Mon, 08 Jan 2007 14:28:43 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H40Ai-00060G-KJ for tls@ietf.org; Mon, 08 Jan 2007 14:28:43 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA00598; Mon, 8 Jan 2007 20:28:34 +0100 (MEZ) From: Martin Rex Message-Id: <200701081928.UAA02974@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Mon, 8 Jan 2007 20:28:35 +0100 (MET) In-Reply-To: <00ab01c7313b$091326b0$6801a8c0@rps.local> from "Mark Brown" at Jan 5, 7 08:33:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Regarding performance estimates, whether you use a FIPS 140 accelerator or > not, the cost of two digital signatures and the extra TLS Evidence messages > is less than the 20+ round trips made to load the page, even if the client > is using multiple connections. In the past I have seen 2 measurements with hardware crypto involved in digital signature generation for use in a backend application server, and both times, the price was high and the performance was unconvincing. One was a crypto hardware on a PCI extension board for PCs being used for an SPKM1 mechanism, and the other was an NCipher crypto box with SCSI-Interface being used for the Server side of SSL. The were two problems: (1) latency setting up the crypto hardware for each individual operation. for the SPKM1 mechanism using digital-signature based MICs, this resulted in 9milliseconds per message protection call. (2) doesn't scale as well as multi-core/multi-CPU setups that are being used these days. I my test setup, a current dual-Xeon (plus HT) running Linux machine was just as fast as an older dual-CPU Solaris workstation with the SCSI-attached NCipher box. Longer RSA keys will favour the hardware approach, but still, the performance/price ratio of the crypto hardware seems to have difficulty competing with raw CPU horsepower, especially for blade-size&cost server setups. The bottleneck in some of the entry-level crypto hardware solutions might be in the smartcard interface (io speed). And the performance of serial SmartCard readers for end users performing RSA crypto operations is > 100x slower than software-based RSA on a PC, so you really don't want to have any of these participating every roundtrip of your communication. Btw. in some scenarios, when clients are authenticated based on X.509 certs (e.g. on an SSL/TLS Web Server) it might at least as important to protect the list of trust anchors from tampering as to guard the servers keypair... -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 08 16:44:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42H6-00029y-Uv; Mon, 08 Jan 2007 16:43:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42H6-00029t-Eh for tls@ietf.org; Mon, 08 Jan 2007 16:43:24 -0500 Received: from simmts6-srv.bellnexxia.net ([206.47.199.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H42H5-0001X8-4B for tls@ietf.org; Mon, 08 Jan 2007 16:43:24 -0500 Received: from pbo8f8e10aowa ([65.94.221.148]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070108214320.GKUP9685.simmts6-srv.bellnexxia.net@pbo8f8e10aowa>; Mon, 8 Jan 2007 16:43:20 -0500 Message-ID: <002401c7336e$37e82b90$94dd5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: , "Mark Brown" References: <200701042049.VAA04275@uw1048.wdf.sap.corp> <001801c7311f$60eeabf0$7daf5e41@pbo8f8e10aowa> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Mon, 8 Jan 2007 16:44:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org see inserted: ----- Original Message ----- From: "Omirjan Batyrbaev" To: ; "Mark Brown" Cc: Sent: Friday, January 05, 2007 6:15 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > see inserted: > ----- Original Message ----- > From: "Martin Rex" > To: "Mark Brown" > Cc: > Sent: Thursday, January 04, 2007 3:49 PM > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > > > Mark Brown wrote: > > > > > > Isn't this attack possible with today's web sales? I mean, once you > give > > > your credit card to anyone, can't they ring you out at any price they > want? > > > You don't need a website or TLS to do this attack. You can do this on > the > > > phone or via mail order. > > > > > > So in the case of TLS Evidence, you both have a record of (1,499,999.-) > > > instead of what the buyer thought, (99,999.-). So what? In both cases > the > > > buyer cancels the order. You don't need TLS Evidence to cancel...with > > > either the merchant or by contacting your credit card issuer. > > > > No I am confused. > > > > Since you just completely disclaimed the usefulness of TLS evidence > > for just about every business application, what's left? > > I have more "disclaimers": at least in US and at least one big b2b exchange > said that they have a simple non-repudiation practice: > they make customers (buyers and sellers) to sign the agreement that > stipulates that whatever is the record of a transaction in the exchange > database that holds as the non-repudable record. (the name witheld due to > the NDA). So they have no need for even application level non-repudiation. > Also consumers in US have Reg A that allows them to repudiate transactions > even if a business has evidence. > -Omirjan > > > > > I don't see anything besides law enforcement, law enforcement usage has a number of "disclaimers" too. For example, the criminals can simply refuse to upgrade their clients to the software that has the evidence software in it. -Omirjan >>and I have serious > > problems in making cleartext escrow plus digital signing of > > the communication an IETF working group item. > > > > -Martin > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 12:20:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Kck-0008PG-Hm; Tue, 09 Jan 2007 12:18:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Kcj-0008P4-1v for tls@ietf.org; Tue, 09 Jan 2007 12:18:57 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Kcc-0007Bc-GO for tls@ietf.org; Tue, 09 Jan 2007 12:18:57 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 9 Jan 2007 17:18:50 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 9 Jan 2007 17:18:49 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Tue, 9 Jan 2007 17:18:46 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Accw+0/vlHsuLwpdQrmHVa92WLOOVwDEvrHw Message-ID: References: from "Stefan Santesson" at Jan 5, 7 05:34:12 pm <200701051857.TAA22968@uw1048.wdf.sap.corp> In-Reply-To: <200701051857.TAA22968@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, I'm trying to engage in a constructive dialogue. I don't know everything an= d I doubt that you do. So can we have this discussion with a little less fl= ame? I think you misunderstand my problem statements. Both user authentication a= nd signing of transactions in interactive web services such as on-line bank= ing has historically been problematic and forced users to use either extern= al devices or download client plug-ins. I haven't followed this lately but = last time I checked this was still an issue. I'm simply curious whether this solution has a place or not. The solution i= tself does not have a serious security flaw. But the way it is used can, if= used improperly. I think we can leave the DMZ out of this. There are different architectures= with different problems. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 5 januari 2007 10:57 > To: Stefan Santesson > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > > Stefan Santesson wrote: > > > > I don't think this discussion is fair to the proposal, > > but in a way it is what I expected to see when bringing > > the concept of "evidence" to a TLS group. > > > > If we leave the concept of evidence out of scope and leave > > it to the lawyers to worry about, is there any technical merits? > > > > There is one that I think we should consider. > > If a client or a server want to ask its opponent > > to sign a portion of data, is there any alternative > > solutions that would work cross platforms. > > Of course there are, and have been in active and successful use for > more than a year. > > They're at least as portable as the TLS implementation itself. > > > > > PKCS#7/CMS or XML digsig is not an answer as it only provides > > signature format, it does not deal with the request and response > logic. > > You're kidding. You wouldn't know how to implement a function in > an application UI that requests a signed Document (PDF,CMS,XMLsig) > from the backend? In the HTML-world of the Internet this thing > is called Hyperlink/URL. > > When Kerberos5-PKINIT was polluted ("enriched") with CMS and OCSP stuff > you didn't seem to have a problem, and there is a proposal to ram > Kerberos/GSS-API into TLS, so it is a total mystery to me why > you suddenly try to make a problem out of CMS. > > The big advantage with this approach is that you don't need any > additional > APIs in order to retrieve TLS evidence from deep down, no new APIs to > perform verification of the signature, it works perfectly fine with > the installed base of middleware and client-software and best of > all, you don't need thousands of case-specific custom software to > make sense and visualize the raw network data of a TLS Evidence > capture. > > > > > > Going higher up closer to the application requires standardization of > > solutions based on vendor specific interpretation languages such as > > Java or .NET. > > If that was anywhere as difficult as you think, then we wouldn't > have PDFs or SWFs. > > Since right now, and for some considerable time to come, > frontend/client- > signing will still be rare and it is a total non-issue for the > backend/server-signing. > > > > > > The balance is a delicate problem. But I'm sure that if there is a > > solution that is technically sound from a protocol perspective, > > then there will be a way to implemented in a sufficiently secure > > way for many usages. > > TLS Evidence doesn't fit into the TLS architecture AT ALL, > and there is an irresponsibly huge hazard that apps will use > it all the wrong fashion and end users will be hopelessly > confused about whether a TLS popup is about online > authentication or a digital signature, so that a large > number of applications will get it totally wrong. > > It is about a good idea as using pure liquide nitroglycerine. > > Responsible security engineers should stay away from this > as far as they can. Our standards should not only be secure, > but also fairly safe to use. > > > > > As to the security discussion earlier, a very common way to > > eliminate the insecure DMZ is to publish the web server from > > a secure front end firewall holding and/or controlling the TLS keys. > > Unless you can hack that firewall you won't get to the keys or > > the server app side of the information flow. In any case, just > > because there is a way to implement a solution badly, does not > > mean that there is no good way to do it. > > Get real. > > The only reason that we have DMZs is that "businesses" insist > on running feature-bloated, bug-ridden applications on the > public internet which will have serious vulnerabilities found > and published on a weekly, if not daily basis for decades to come. > > It really doesn't matter which application vendor you pick, all > of them are affected, just that some of them are more attractive > targets than others, have more vulernabilities published on a > regular basis and therefore pose a higher risk for their operators > of successful hacks/break-ins. > > DMZs are used to host the machines and "frontends" of web-shops, > as a first line of defense, and they are supposed to filter > and pre-process requests&data before submitting it for processing > to a backend system on the internal network which hosts the > vital company data. By closely monitoring the traffic within > the DMZ and between the app/proxy in the DMZ and the backend > system, you have significantly higher chances to notice and > stop attackers from reaching your vital backend system. > > This approach works remarkably well, and it is being done > that way for more than a decade now. > > > I find it quite distracting that everytime that I show obvious > vulnerabilities an a proposed application scenario making use > of TLS Evidence that someone says: Oh, that is obvious fraud-- > we don't worry about that, we can give it to the police and sue... > > Sorry, but that is the stupid reaction from a markedroid, definitely > not from a security-experienced engineer. A good design doesn't > have such vulnerabilities. Substituting security engineering and > good design with evidence collecting for law enforcement agency > and passing on the scapegoat to them is the most stupid approach > to security that I've ever heard in a working group of the IETF > security area. > > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 14:16:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MRd-0004bX-4v; Tue, 09 Jan 2007 14:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MRc-0004bQ-C8 for tls@ietf.org; Tue, 09 Jan 2007 14:15:36 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4MRa-0002Cs-TK for tls@ietf.org; Tue, 09 Jan 2007 14:15:36 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA06898; Tue, 9 Jan 2007 20:15:25 +0100 (MEZ) From: Martin Rex Message-Id: <200701091915.UAA21473@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: stefans@microsoft.com (Stefan Santesson) Date: Tue, 9 Jan 2007 20:15:24 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 9, 7 05:18:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dear tls fanciers, I want to apologize for my offensive language in this discussion, it was quite inappropriate. I'm sorry. My problem is, I am REALLY scared by this TLS evidence proposal, because of (a) I consider it a very bad idea to create protocols in a way that digital signatures over something when the signer and the receipients of the signed data are not fully aware and consenting about every meaningful bit in the signed data and also fully aware and consenting about each signature operation (b) its obvious, real and enormous potential of abuse of the proposed "application doesn't know, TLS stack collects evidence for third party" approach. (c) I consider it an extremely bad idea to subvert the current TLS architecture and abuse a key pair that has been used in a proof-of-presense for online authentication for digitally signing of raw communication data. (d) because it archtectually doesn't fit AT ALL into basically all of the existing (serious and security-conscious) SSL/TLS deployments that *I* know (e) because of the many and serious security vulerabilities that will arise when this technologies becomes available in the installed base of SSL/TLS deployments The architecture is a security disaster for many threat models that I can think of, and if the response to this is "Oh, I don't care about your threat models, I have my very own limited threat model and very esoteric deployment where your concerns don't matter, and should they do I'm confident that some lawyer can take over and deal with the damage and probably sue, then this really scares the shit out of me. In the IETF, we normally try to come up with good engineering solutions. And if there are clear architectural problems in not so uncommon SSL/TLS deployments integrating this proposal, and also clear security vulerabilities for common deployments, then an effective denial (oh, that's not the usage scenario I'm looking for), is unlikely to get us anywhere near a generally useful protocol extension that integrates smoothly with existing deployments, is safe to use and very difficult to abuse. Stefan Santesson wrote: > > I think you misunderstand my problem statements. Both user > authentication and signing of transactions in interactive > web services such as on-line banking has historically been > problematic and forced users to use either external devices > or download client plug-ins. I haven't followed this lately > but last time I checked this was still an issue. I do NOT consider this an "ISSUE", it is the only reasonable approach, is less confusing to the user in that there is a huge difference between online-authentication and digital signatures and are much harder to abuse in that digital signatures are going to be pushed out to users in a covert fashion. Why does Microsoft want a tigther integration between TLS and Kerberos authentication? Because this is what customers desperately want in order to do single Sign-On. Just that the TLS Evidence is mutually exclusive with a lot of things, including cert-less single sign-on with Kerberos. One generic approach to creation of digital signatures (or two, one for the frontend and one for the backend), that will work independent of the online authentication scheme that is being used will be so much better for all of us, and in particular for the average end user. > > I'm simply curious whether this solution has a place or not. TLS Evidence is the most evil protocol extension (proposal) I am aware of. > > The solution itself does not have a serious security flaw. On my scorecard it has several security flaws. > > But the way it is used can, if used improperly. That's an interesting way to put it. If I get around to it, I'll put it up for the next BigBrother award. > > I think we can leave the DMZ out of this. There are different > architectures with different problems. Really bad idea. DMZ has significant security benefits and is being used and necessary in many SSL/TLS deployments. It already was a good idea 10 years ago, when you didn't have weekly 0-day vulnerability reports. Responsible sysadmins of large companies do not only use a DMZ to seperate the company network from the internet, they also have one or more internal networks seperated with a DMZ from the company internal network. And even without a "full blown" DMZ, the main characteristic of a single entry point through an SSL Accellerator or Reverse Proxy with Load-balancer is the norm for large-scale application deployment using web-based presentation frontends. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 14:53:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4N1j-0002Ra-TC; Tue, 09 Jan 2007 14:52:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4N1i-0002RO-O5 for tls@ietf.org; Tue, 09 Jan 2007 14:52:54 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4N1h-0003vk-6y for tls@ietf.org; Tue, 09 Jan 2007 14:52:54 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 9 Jan 2007 19:52:52 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 9 Jan 2007 19:52:52 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Tue, 9 Jan 2007 19:52:50 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc0Io/83J2KFygqQYecxQqrd1yC6QAAXFyg Message-ID: References: from "Stefan Santesson" at Jan 9, 7 05:18:46 pm <200701091915.UAA21473@uw1048.wdf.sap.corp> In-Reply-To: <200701091915.UAA21473@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Thank you for your efforts to explain your position. Let me first clarify that I'm not arguing for this solution. I have my own = doubts. I'm just looking at it with an open mind. A few comments; What this proposal do technically is to offer a way to sign a portion of th= e data flow using TLS keys. That is all it does it does without a security = flaw (thus evidence in my mind is a bad word in this spec). It does not provide any evidence of user consent. If any attempt was done t= o do so at the TLS layer. I would object loudly. Providing evidence of user consent is a separate and complex issue where th= is might be a building block, but not the complete solution. The same is tr= ue for many other "solid" security protocols providing data integrity and d= ata origin authentication. CMS as a standard does not guarantee user consen= t, but it can be a useful component in a larger solution doing so. Clarifying my DMZ remark: DMZ is often an important component of a system architecture. Looking at in= dividual applications, DMZ may be a good or a bad choice. The challenge wit= h using a DMZ is sometimes that you may have to open many holes through the= back end firewall to allow the front end application in the DMZ to talk to= back end resources. So in some cases an alternative is to simply put a pro= xy in the back end firewall with application level inspection, thus reducin= g the number of open ports and encrypted channels through the firewall. Mod= ern network security design simply offers many valid choices. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 9 januari 2007 11:15 > To: Stefan Santesson > Cc: martin.rex@sap.com; tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > Dear tls fanciers, > > I want to apologize for my offensive language in this discussion, > it was quite inappropriate. I'm sorry. > > My problem is, I am REALLY scared by this TLS evidence proposal, > because of > > (a) I consider it a very bad idea to create protocols in a way that > digital signatures over something when the signer and the > receipients of the signed data are not fully aware and consenting > about every meaningful bit in the signed data and also fully > aware and consenting about each signature operation > > (b) its obvious, real and enormous potential of abuse of the proposed > "application doesn't know, TLS stack collects evidence for third > party" > approach. > > (c) I consider it an extremely bad idea to subvert the current > TLS architecture and abuse a key pair that has been used > in a proof-of-presense for online authentication for > digitally signing of raw communication data. > > > (d) because it archtectually doesn't fit AT ALL into basically all of > the existing (serious and security-conscious) SSL/TLS deployments > that *I* know > > (e) because of the many and serious security vulerabilities that will > arise when this technologies becomes available in the installed > base of SSL/TLS deployments > > > The architecture is a security disaster for many threat models that > I can think of, and if the response to this is "Oh, I don't care > about your threat models, I have my very own limited threat model > and very esoteric deployment where your concerns don't matter, > and should they do I'm confident that some lawyer can take over > and deal with the damage and probably sue, then this really > scares the shit out of me. > > In the IETF, we normally try to come up with good engineering > solutions. And if there are clear architectural problems > in not so uncommon SSL/TLS deployments integrating this > proposal, and also clear security vulerabilities for common > deployments, then an effective denial (oh, that's not the > usage scenario I'm looking for), is unlikely to get us > anywhere near a generally useful protocol extension > that integrates smoothly with existing deployments, > is safe to use and very difficult to abuse. > > > > Stefan Santesson wrote: > > > > I think you misunderstand my problem statements. Both user > > authentication and signing of transactions in interactive > > web services such as on-line banking has historically been > > problematic and forced users to use either external devices > > or download client plug-ins. I haven't followed this lately > > but last time I checked this was still an issue. > > I do NOT consider this an "ISSUE", it is the only reasonable approach, > is less confusing to the user in that there is a huge difference > between online-authentication and digital signatures and > are much harder to abuse in that digital signatures are going > to be pushed out to users in a covert fashion. > > Why does Microsoft want a tigther integration between TLS > and Kerberos authentication? Because this is what customers > desperately want in order to do single Sign-On. Just that > the TLS Evidence is mutually exclusive with a lot of things, > including cert-less single sign-on with Kerberos. > > One generic approach to creation of digital signatures > (or two, one for the frontend and one for the backend), > that will work independent of the online authentication > scheme that is being used will be so much better for all > of us, and in particular for the average end user. > > > > > > I'm simply curious whether this solution has a place or not. > > TLS Evidence is the most evil protocol extension (proposal) I am aware > of. > > > > > The solution itself does not have a serious security flaw. > > On my scorecard it has several security flaws. > > > > > > But the way it is used can, if used improperly. > > That's an interesting way to put it. > If I get around to it, I'll put it up for the next BigBrother award. > > > > > I think we can leave the DMZ out of this. There are different > > architectures with different problems. > > Really bad idea. DMZ has significant security benefits and > is being used and necessary in many SSL/TLS deployments. > It already was a good idea 10 years ago, when you didn't > have weekly 0-day vulnerability reports. > > Responsible sysadmins of large companies do not only use a DMZ > to seperate the company network from the internet, they also > have one or more internal networks seperated with a DMZ > from the company internal network. And even without a > "full blown" DMZ, the main characteristic of a single entry point > through an SSL Accellerator or Reverse Proxy with Load-balancer > is the norm for large-scale application deployment using > web-based presentation frontends. > > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 15:33:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Nek-0001Ca-S7; Tue, 09 Jan 2007 15:33:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Nej-0001CV-VV for tls@ietf.org; Tue, 09 Jan 2007 15:33:13 -0500 Received: from simmts8-qfe0.srvr.bell.ca ([206.47.199.166] helo=simmts8-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Nei-0008DE-Kh for tls@ietf.org; Tue, 09 Jan 2007 15:33:13 -0500 Received: from pbo8f8e10aowa ([65.94.175.166]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070109203307.RAQD18487.simmts8-srv.bellnexxia.net@pbo8f8e10aowa>; Tue, 9 Jan 2007 15:33:07 -0500 Message-ID: <001c01c7342d$92f4fc10$a6af5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: , "Stefan Santesson" References: <200701091915.UAA21473@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Tue, 9 Jan 2007 15:34:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org see inserted: >> Stefan Santesson wrote: > > > > I think you misunderstand my problem statements. Both user > > authentication and signing of transactions in interactive > > web services such as on-line banking has historically been > > problematic and forced users to use either external devices > > or download client plug-ins. I haven't followed this lately > > but last time I checked this was still an issue. > > I do NOT consider this an "ISSUE", it is the only reasonable approach, > is less confusing to the user in that there is a huge difference > between online-authentication and digital signatures and > are much harder to abuse in that digital signatures are going > to be pushed out to users in a covert fashion. I agree with the above statement from Martin. Majority of the banks found ways to manage the risk. If the issue was raised 10 or more years ago it may have been different. BTW, when I used wells fargo (wellsfargo.com) in 2003 I was able to transfer money between accounts with a simple user name / password authentication. But I did hear about other solutions employed by non-US banks - but they look at them as a satisfactory solutions. -Omirjan > > Why does Microsoft want a tigther integration between TLS > and Kerberos authentication? Because this is what customers > desperately want in order to do single Sign-On. Just that > the TLS Evidence is mutually exclusive with a lot of things, > including cert-less single sign-on with Kerberos. > > One generic approach to creation of digital signatures > (or two, one for the frontend and one for the backend), > that will work independent of the online authentication > scheme that is being used will be so much better for all > of us, and in particular for the average end user. > > > > > > I'm simply curious whether this solution has a place or not. > > TLS Evidence is the most evil protocol extension (proposal) I am aware of. > > > > > The solution itself does not have a serious security flaw. > > On my scorecard it has several security flaws. > > > > > > But the way it is used can, if used improperly. > > That's an interesting way to put it. > If I get around to it, I'll put it up for the next BigBrother award. > > > > > I think we can leave the DMZ out of this. There are different > > architectures with different problems. > > Really bad idea. DMZ has significant security benefits and > is being used and necessary in many SSL/TLS deployments. > It already was a good idea 10 years ago, when you didn't > have weekly 0-day vulnerability reports. > > Responsible sysadmins of large companies do not only use a DMZ > to seperate the company network from the internet, they also > have one or more internal networks seperated with a DMZ > from the company internal network. And even without a > "full blown" DMZ, the main characteristic of a single entry point > through an SSL Accellerator or Reverse Proxy with Load-balancer > is the norm for large-scale application deployment using > web-based presentation frontends. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 17:11:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PBE-0007PZ-C2; Tue, 09 Jan 2007 17:10:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PBC-0007PF-MJ for tls@ietf.org; Tue, 09 Jan 2007 17:10:50 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4PBB-0004RT-8X for tls@ietf.org; Tue, 09 Jan 2007 17:10:50 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA20899; Tue, 9 Jan 2007 23:10:45 +0100 (MEZ) From: Martin Rex Message-Id: <200701092210.XAA23923@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: batyr@sympatico.ca (Omirjan Batyrbaev) Date: Tue, 9 Jan 2007 23:10:43 +0100 (MET) In-Reply-To: <001c01c7342d$92f4fc10$a6af5e41@pbo8f8e10aowa> from "Omirjan Batyrbaev" at Jan 9, 7 03:34:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Omirjan Batyrbaev wrote: > > ... Majority of the banks found > ways to manage the risk. If the issue was raised 10 or more years ago it may > have been different. BTW, when I used wells fargo (wellsfargo.com) in 2003 I > was able to transfer money between accounts with a simple user name / > password authentication. But I did hear about other solutions employed by > non-US banks - but they look at them as a satisfactory solutions. I don't think that Online Banking (customer<->bank) is an area that is in desperate need of (TLS) Evidence. In many if not most scenarios that I know, the customer has to deal with / pay for the majority of fraud, making it an "externality" for the bank, which is why e.g. there are lots of el'cheapo ATM cards in use (at least here in Germany), i.e. simple magnetic strip cards that can be copied, and only its use protected by a 4-digit Number/PIN. Online Banking (at least here in Germany) often involves an OTP-style authentication (TAN) to authorize each individual transaction. Personally, I'm fine with that (although I will NOT do Online Banking in an Internet Cafe or from arbitrary people's PCs). As you mentioned, there are consumer protection acts that shield customers from some of the bad things around online shopping (at least in Germany, consumer protection curiously does not cover many aspects online and offline banking), and so a signing scheme like TLS Evidence scheme might not help businesses, and due to the data protection standards in the EU, such a TLS approach may even be illegal in a lot of scenarios or impose a lot of additional duties or non-obvious responsibilities on businesses. Businesses must provide accurate information about stored/archived data that can be linked to a subject. The permission to store that data can be revoked by the subject at any time. If revoked, the business is required to completely delete all records. Not complying with the deletion request is a "federal offense". Tough luck if TLS Evidence was blindly streamed to write-once media... Those requirements don't apply to wire-taps of federal agencies, of course. And when/where they apply (after a secret wire-tap that resulted in no legal action), they "sometimes forget" to tell the subject and delete the records... In one of his Emails, Mark wrote "Your typical brokerage transaction", maybe he was thinking of inter-business, or more specifically inter-banking, broker<->bank, bank<->bank, broker<->broker transactions in the financial area. I consider it somewhat strange to design an "evidence" scheme that will be difficult to process/interpret automatically or programmatically because of a lack of standardization of how to perform the verification and how to make sense of the gobbledigoo that travels at the lowest level of the communication. By using standardized contents it will be much easier to process the data programmatically, and you could use even 3 signers: both peers and a timestamping authority. TLS Evidence requires interactive online communication, an application-level signing approach can easily work without transport, accross arbitrary hops/links, with queueing or batch-processing, via Email, and on and on, i.e. entirely independent of the nature and persistence of the communication (link). If one would design the "transaction evidence" from the communication link with clear&explicit application-defined semantics, then it would be possible to programmatically check the archived "evidence" against the app transaction logs on the backend on a regular basis in order to detect differences (du to bugs or system manipulation in the backend) early on. With a raw dump of the communication data this is going to be quite difficult and context-sensitive to changes of the application (data stream), and less likely to be done. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 18:42:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QbI-00034k-4X; Tue, 09 Jan 2007 18:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QbH-00034c-9r for tls@ietf.org; Tue, 09 Jan 2007 18:41:51 -0500 Received: from bay0-omc2-s22.bay0.hotmail.com ([65.54.246.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4QbD-0006Sk-Uy for tls@ietf.org; Tue, 09 Jan 2007 18:41:51 -0500 Received: from hotmail.com ([65.55.131.12]) by bay0-omc2-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 9 Jan 2007 15:41:47 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Jan 2007 15:41:47 -0800 Message-ID: Received: from 67.97.95.201 by BAY126-DAV2.phx.gbl with DAV; Tue, 09 Jan 2007 23:41:42 +0000 X-Originating-IP: [67.97.95.201] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Stefan Santesson" , References: from "Stefan Santesson" at Jan 9, 7 05:18:46 pm<200701091915.UAA21473@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Tue, 9 Jan 2007 15:41:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 09 Jan 2007 23:41:47.0272 (UTC) FILETIME=[BA16B080:01C73447] X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I'm convinced the term "corporate wiretapping" is proper, and that is one that grandma will inevitably associate with the scheme. And, for that reason, we must recognize that we have in our hands the power to destroy consumer trust in the "SSL brandname". Even this debate could be picked up by journalists, today, to SSL's disadvantage. It doesn't take much to destroy trust. In purer circles, TLS Evidence might be called a "mandatory data retention" scheme, to be enforced in the router/loadbalancer infrastructue when your company gets a subpoena demanding evidence retention, for example. And, one should assume every company will be forced there anyways, within 5 years, via best practices policy, to be enforced by the insurers. ---------- SO, having given the scheme a name, we can turn to the policy. The policy behind the scheme smells like mandatory "data/key escrow": but it has clearly evolved, perhaps to something more palatable. But there is no doubt in my mind what the intent is, masked behind several policy enforcement constructs. I can _only_ bring myself to characterize the design intent as a "subversion" - a subversion of the assumed privacy goal of SSL. I've tried for two weeks to convince myself to find a better spin, but cannot honestly do so. And, its not because of the signatures, but because it requires the mandatory storage of the handshake cleartext, even in a double handshake case. (This allow a third party to validate the _stored_ signatures, not only authorize the realtime communication of _recorded_ data). ---------- With all that said, however, the privacy debate _has_ moved on, from its earlier forms: it has both expectation AND obligation components these days These do need suitably designed enforcement constructs, preferably policy driven. And, then, policies need to be tuned for either the corporate or the individual cases. So, I feel that Marc and I _are_ tuned to the same fundamental frequency, in repurposing the SSL handshake in this way. As I indicated earlier, however, connection-NR was my attempt and it was a resounding flop (I turned a sequence of re-handshakes into means of performing legal-obligation-passing protocols; and in my abortive PhD I did the same with a cross-certification protocol for inter-domain obligation passing; both flopped, miserably). Given this characterization of the debate, I believe that David Kemp to be "inappropriately" characterizing the scheme in terms of it being merely an "enhanced DAO" security service (like an aeap/AES-CCM scheme specialises DOA, to adds semantics that enforce "timed" release of the plaintext blocks to the socket user, for example, as well as authenticating a header for a connectionless TLS fragment ). And, I don't believe Russ Housley if he now claims that he is merely exploiting DAO for business/legal-obligation-passing protocols; the prelude presented for the mailing list clearly stated that it is the intent to support multi-level, realtime routing decisions. It is thus my opinion that the scheme aims to "instrument flow control policies in realtime" based on identities and evidence. From Marc's explanations, he intends to apply it to the authorization to even communicate, subject to access control policies - a la TNI. >From what I can deduce, this _is_ all working towards router that do (realtime) testing for the existence of (and presumably validation of) the signature. This will require validating the id certs (from the PIV card, presumably) that sign the evidence, and validating the SSL certs used in the communication endpoints. These combined assurances may then authorize delivery of the applciation data to the layer 4 port, but ONLY once its signed/validated/recorded/stored. Together, these assertions would "authorize" opening the "internet" port, which only open opening would pass TLS fragments (or complete records) to the assured application entities up the stack. Whilst Martin is right to worry about the obvious case of a wiretapping application here, he is wrong to assume the handshake certs/keys are used in the signing process. The scheme does not mandate that one mixing client auth and NR EKUs; they can be in separate certs, on distinct endpoint devices. Perhaps the SSL client cert in one's PC's TPM will be a DSSsignedRSA key, created by one's national id card? ---------- Having used all this control plane terminology, I'll remark on the WG procedural question before us. The debate about voice/data wiretapping has moved on from where it was. So, where has it moved on to? Well, privacy is now no longer only about facilitating your assertion of your expectation of privacy, and providing the strong and assured confidentiality channels; it is also now imposing social obligations on you, in turn. To get the one, you have to accede to the other, in a quid pro quo. At least we have more advanced political concepts, and a vocabulary for concluding a useful debate. For the types of agreement construction being contemplated, its true for me that the SSL handshake and mandatory signature-based flow control regimes are more than an appropriate set of technical measures. But, this is true only when supported by very, very high assurance crypto and recording/storage hardware. ----------- So Ill conclude my contributing to the wiretapping issue by re-posing the only actual question before us: does this group want to adopt this work item, now its (potential) nature is apparent. It's a bold step to turn TLS into a flow control apparatus. It may or may not fit what IETF is about, these days, in my irrelevant opinion. ----- Original Message ----- From: "Stefan Santesson" To: _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 22:43:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UM8-00038b-Bg; Tue, 09 Jan 2007 22:42:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UM6-00038Q-SG for tls@ietf.org; Tue, 09 Jan 2007 22:42:26 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4UM4-0001Yv-Fq for tls@ietf.org; Tue, 09 Jan 2007 22:42:26 -0500 Received: by machshav.com (Postfix, from userid 512) id D1FDAFB40B; Wed, 10 Jan 2007 03:42:17 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 22E36FB3D7; Wed, 10 Jan 2007 03:42:17 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id B0458765FE4; Tue, 9 Jan 2007 22:42:15 -0500 (EST) Date: Tue, 9 Jan 2007 22:42:15 -0500 From: "Steven M. Bellovin" To: martin.rex@sap.com Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <200701092210.XAA23923@uw1048.wdf.sap.corp> References: <001c01c7342d$92f4fc10$a6af5e41@pbo8f8e10aowa> <200701092210.XAA23923@uw1048.wdf.sap.corp> Organization: Columbia University X-Mailer: Claws Mail 2.7.0 (GTK+ 2.10.6; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070110034215.B0458765FE4@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, 9 Jan 2007 23:10:43 +0100 (MET) Martin Rex wrote: > > I don't think that Online Banking (customer<->bank) is an area > that is in desperate need of (TLS) Evidence. In many if not most > scenarios that I know, the customer has to deal with / pay for > the majority of fraud, making it an "externality" for the bank, > which is why e.g. there are lots of el'cheapo ATM cards > in use (at least here in Germany), i.e. simple magnetic strip cards > that can be copied, and only its use protected by a 4-digit > Number/PIN. > That's very much dependent on local laws. In the US, it's generally the bank that pays, partially in response to competitive pressures. And there are still plenty of ATM cards, with just a mag stripe and PIN. (See p. 203 of Ross Anderson's "Security Engineering", which you can download from http://www.cl.cam.ac.uk/~rja14/book.html -- that page is in chapter 9.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 09 22:44:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UNX-0003aY-GG; Tue, 09 Jan 2007 22:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UNW-0003aQ-9O for tls@ietf.org; Tue, 09 Jan 2007 22:43:54 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4UNU-00024y-SN for tls@ietf.org; Tue, 09 Jan 2007 22:43:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id F2B8434004; Wed, 10 Jan 2007 16:43:49 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25574-16; Wed, 10 Jan 2007 16:43:49 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id C9D8A33FDE; Wed, 10 Jan 2007 16:43:49 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2F6BE12807F; Wed, 10 Jan 2007 16:43:49 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1H4UNW-0005jZ-00; Wed, 10 Jan 2007 16:43:54 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <200701091915.UAA21473@uw1048.wdf.sap.corp> Message-Id: Date: Wed, 10 Jan 2007 16:43:54 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: >I want to apologize for my offensive language in this discussion, it was >quite inappropriate. I've been sitting back watching the debate go on and on for awhile (which is pretty unusual for me :-), and this proposal seems both extremely controversial and beset with large numbers of problems. In this case why not give it either 'Experimental' status (in order to gain more experience with the can of worms that it opens up), or make it a private RFC rather than a TLS WG item? That would seem to resolve the problem, because I'm not sure that continuing debate will do more than point out even more problems with it. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 09:58:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4esi-00005C-TM; Wed, 10 Jan 2007 09:56:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4esh-000057-Tc for tls@ietf.org; Wed, 10 Jan 2007 09:56:47 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4esd-0003Zj-E9 for tls@ietf.org; Wed, 10 Jan 2007 09:56:47 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA04261; Wed, 10 Jan 2007 15:54:31 +0100 (MEZ) From: Martin Rex Message-Id: <200701101450.PAA06386@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: home_pw@msn.com Date: Wed, 10 Jan 2007 15:50:57 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 9, 7 03:41:42 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > I'm convinced the term "corporate wiretapping" is proper, > > In purer circles, TLS Evidence might be called a "mandatory > data retention" scheme, to be enforced in the > router/loadbalancer infrastructue when your company gets a > subpoena demanding evidence retention, for example. And, one > should assume every company will be forced there anyways, > within 5 years, via best practices policy, to be enforced by > the insurers. I thought about the EU data protection act a little further, and I'm convinced that in case that the signature identifies an individual subject, then persisting the TLS Evidence data is probably almost always going to be illeagal within the entire EU. See http://europa.eu.int/ISPO/legal/en/dataprot/protection.html and http://www.e-dialog.com/pdf/2003_12_EU_%20Data_%20Protection_%20Act%20POV.pdf Although it is possible to ask each individual subject for permission of storing the data, there are so many formal requirements that a blind capture of the communication stream at the network level will make it difficult to impossible to even obtain a formally correct confirmation of user consent before persisting the data. A list of issues: - the subject's consent must be obtained before persisting the data - the subject's consent must be absolutely voluntary, asserting any kind of pressure on the subject is a criminal offense - the consent agreement must contain a DETAILED list of the information that is to be persisted, a description of exactly what is going to be done with it, how long it is going to be kept, whether and exactly which third party will have access to the data and for what specific purpose. - the subject may revoke the consent to store/persist the data at any time with no reason given, with the effect that all recordings of the data must be DELETED all third parties that were authorized to receive this data must be notified of the revocation of the consent agreement and also DELETE all records of the data. - everyone who stores/persists the data must provide detailed information on what data/records is/are kept if the subject asks for it. With the signature on the raw data, it is impossible to delete unnecessary data without invalidating the signature/evidence. The EU data protection act also has a requirement that persistance of data that can be linked to an individual subject MUST be minimized. TLS-Evidence covering a HTTP GET can easily violate this rule by containing a "User-Agent:" header identifying a users OS make&release and Browser Make&version, and potentially worse, an off-site HTTP-Referer when deep-linking was used to get here. For the business transaction, a trace&signature of the transaction (request) at the application level will not contain User-Agent: and Http-Referer: so TLS Evidence is clearly inappropriate technology. Producing a formally correct consent agreement to properly identify such details are really challenging, but they're impossible without interpreting/decoding the entire contents of the recorded (raw) data. Obtaining the consent agreement with a detailed listing of what data is going to be persisted will be impossible without significant changes to the (communication architecture) of an application. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 10:03:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4eyZ-0002eq-7N; Wed, 10 Jan 2007 10:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4eyY-0002ej-P9 for tls@ietf.org; Wed, 10 Jan 2007 10:02:50 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4eyP-0004S4-OV for tls@ietf.org; Wed, 10 Jan 2007 10:02:50 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA10768; Wed, 10 Jan 2007 16:02:25 +0100 (MEZ) From: Martin Rex Message-Id: <200701101502.QAA06562@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: home_pw@msn.com Date: Wed, 10 Jan 2007 16:02:22 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 9, 7 03:41:42 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > And, I don't believe Russ Housley if he now claims that he > is merely exploiting DAO for > business/legal-obligation-passing protocols; the prelude > presented for the mailing list clearly stated that it is the > intent to support multi-level, realtime routing decisions. > It is thus my opinion that the scheme aims to "instrument > flow control policies in realtime" based on identities and > evidence. From Marc's explanations, he intends to apply it > to the authorization to even communicate, subject to access > control policies - a la TNI. > > From what I can deduce, this _is_ all working towards router > that do (realtime) testing for the existence of (and > presumably validation of) the signature. This will require > validating the id certs (from the PIV card, presumably) that > sign the evidence, and validating the SSL certs used in the > communication endpoints. These combined assurances may then > authorize delivery of the applciation data to the layer 4 > port, but ONLY once its signed/validated/recorded/stored. > Together, these assertions would "authorize" opening the > "internet" port, which only open opening would pass TLS > fragments (or complete records) to the assured application > entities up the stack. I'm sorry, but I completely fail to understand why it is necessary to sign and persist the entire raw network communication for that purpose. From what you describe, the only thing that is being programatically done is the verification of a signature, potentially with a different cert than what was used to authenticated the original TLS connection. I really don't see why it one cannot use another approach to perform a secure "channel binding" with mutual signature verification that does not have any of the serious security implications of the TLS proposal. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 10:22:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fGW-0003L3-Ua; Wed, 10 Jan 2007 10:21:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fGW-0003Kp-A8 for tls@ietf.org; Wed, 10 Jan 2007 10:21:24 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4fGT-0006Yx-Uz for tls@ietf.org; Wed, 10 Jan 2007 10:21:24 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0AFLLGs018815 for ; Wed, 10 Jan 2007 10:21:21 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Wed, 10 Jan 2007 10:21:21 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Jan 2007 10:21:21 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Wed, 10 Jan 2007 10:21:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc0R+7PiO7c12ZvR/a+hhYaXgPVNgAeuHSA From: "Kemp, David P." To: X-OriginalArrivalTime: 10 Jan 2007 15:21:21.0375 (UTC) FILETIME=[FBAC26F0:01C734CA] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14926003 X-TM-AS-Result: : Yes--9.023400-0-1-1 X-TM-AS-Category-Info: : 1:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDIz?= =?us-ascii?B?NTgtNzA3MjkyLTEwNTA0MC03MDQ5ODMtNzAxOTI3LTcwMjE0Ni03?= =?us-ascii?B?MDY0MjctNzAwNzU2LTcwMTQ2MS03MDE3NTItNzAyMjY0LTcwODc5?= =?us-ascii?B?Mi03MDE3NDktNzAzOTg4LTcwMzQ2OC03MDk0MTUtNzAxMjk3LTcw?= =?us-ascii?B?MTc0MS03MDQ2NDUtNzAzOTY0LTcwNzIyNS03MDE1NDItNzAwOTU1?= =?us-ascii?B?LTEyMTYyOC0xMDY0NzAtNzAwNDc4LTcwMjM4OC03MDM4NzUtNzAy?= =?us-ascii?B?MTI2LTcwMjcyNi03MDM1ODUtNzAxNDU1LTcxMDc0Mi03MDQ5Nzct?= =?us-ascii?B?NzAyMDU0LTEzOTAwNi03MDAwMzYtNzAwMDczLTcwMTk2MC0xMDYy?= =?us-ascii?B?MzAtNzA2ODkxLTcwNDAzMS03MTE3ODEtNzAwNzUyLTcwNTU4My03?= =?us-ascii?B?MDMwNjEtMTQ4MDUw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Like cookies destroyed grandma's trust in the SSL brand? Yet how many web sites still use cookies, and how many browsers allow users an easy way to both disable cookies entirely or selectively, and delete stored cookies entirely or selectively? If cookies are such a trust buster, why are they still used? A: Because they provide a useful capability. Browser support for TLS extensions would be just as much under the user's control as cookies and ciphersuites. This extension doesn't even exist for grandma unless she goes to the trouble of obtaining a client cert - is your grandma that tech-savvy? And even if she can request and install a client cert, there is no stealth involved in that process :-). The purpose of the proposal is to explore options to allow certificate-enabled clients to provide broadcast (1-to-many) persistent authentication without having to install SOA (WS-*) or other signing-capable plugins on the client. It may or may not be architecturally a better choice to do signing through Web Services vs. TLS. But while you're crying crocodile tears over TLS's "reputation" should it ever gain the ability to do digital signatures, save a few for Vista and digital IDs. Consumer-to-provider authentication (as opposed to consumer-to-provider's-TLS-accelerator) is needed, has both benefits and the abuse potential you are worried about, and is happening regardless of whether TLS is extended. Dave -----Original Message----- From: home_pw@msn.com [mailto:home_pw@msn.com]=20 Sent: Tuesday, January 09, 2007 6:42 PM To: Stefan Santesson; martin.rex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< I'm convinced the term "corporate wiretapping" is proper,=20 and that is one that grandma will inevitably associate with=20 the scheme. And, for that reason, we must recognize that we=20 have in our hands the power to destroy consumer trust in the=20 "SSL brandname". Even this debate could be picked up by=20 journalists, today, to SSL's disadvantage. It doesn't take=20 much to destroy trust. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 13:54:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iZG-0000bD-QM; Wed, 10 Jan 2007 13:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iZF-0000b8-5T for tls@ietf.org; Wed, 10 Jan 2007 13:52:57 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4iZA-0000Wo-Q5 for tls@ietf.org; Wed, 10 Jan 2007 13:52:57 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 10 Jan 2007 18:52:46 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 10 Jan 2007 18:52:46 +0000 From: Stefan Santesson To: "tls@ietf.org" Date: Wed, 10 Jan 2007 18:52:40 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc0aa1NV7LdJvSLQLOXd98ptbJiTAAeFfkw Message-ID: References: <200701091915.UAA21473@uw1048.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BEUI DKE/ DVCt FOAO Gq54 G439 HYuP H2bD IQnl I0/O JUQ4 JtHW KCl9 KEtu K4pR K5j2; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {39FB3ADB-91A7-4FF9-B681-410C43EC1C91}; cwB0AGUAZgBhAG4AcwBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A; Wed, 10 Jan 2007 18:52:40 GMT; UgBFADoAIABbAFQATABTAF0AIABQAGwAZQBhAHMAZQAgAGQAaQBzAGMAdQBzAHMAOgAgAGQAcgBhAGYAdAAtAGgAbwB1AHMAbABlAHkALQBlAHYAaQBkAGUAbgBjAGUALQBlAHgAdABuAHMALQAwADAAPAA= x-cr-puzzleid: {39FB3ADB-91A7-4FF9-B681-410C43EC1C91} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org After paying careful attention to this debate, I would like to summarize my= view on this proposal and give my recommendation to the WG. My conclusion is that if the legal perspective of this proposal is removed,= then it has potential and I would therefore vote YES to accept this draft = as a TLS WG item. The proposal can provide a relatively simple mechanism to authenticate even= ts, such as agreements, conducted over a TLS session and there is no workin= g, off the shelf, alternative solution available today that works cross pla= tforms. Example scenario: The server side wants to present a some data to the client that the user ha= s to accept. Such as agreeing to a purchase order. If this is to be a signed agreement, we have building blocks like http get,= CMS, XML DigSig and WS*, but they don't provide a complete solution for th= e whole chain of events from formatting the request from the server to invo= ke a signed acceptance, presenting the data in a way that is processed and = uniformly displayed by the client, UI invocation for user consent, signing = and returning the signed data. This proposal provides an interesting "low budget" alternative by adding au= thentication to approvals that otherwise work just the way most businesses = do today (based on plain http) but where the conversation making up this "a= cceptance" could be authenticated by a signature. This would add to the cur= rent level of security of a procedure that is already in use in many busine= sses. Adding this feature would have minimal impact on current application = software and business systems. By doing this on the TLS layer many aspects = of the "acceptance" could automatically be recorded such as client software= version and html code provided for the data presentation. Things that adds= to the audit value but would take enormous standards effort to get capture= d and documented in an application layer signature. The TLS group should not speculate in the legal consequences of adding this= authentication mechanism, but should make sure that the protocol is well d= efined and technically sound. Special attention should be given to developm= ent of a good security considerations section. In the end of this process we will either have a good and solid protocol ex= tension to TLS or have reached a point where we realize that this is a bad = idea. But I strongly believe that this document, if developed, should be de= veloped under TLD WG review and change control. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 15:33:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4k7a-0003RG-Dz; Wed, 10 Jan 2007 15:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4k7Y-0003R5-Na for tls@ietf.org; Wed, 10 Jan 2007 15:32:28 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4k7X-000415-BU for tls@ietf.org; Wed, 10 Jan 2007 15:32:28 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA09671; Wed, 10 Jan 2007 21:32:17 +0100 (MEZ) From: Martin Rex Message-Id: <200701102032.VAA12262@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: stefans@microsoft.com (Stefan Santesson) Date: Wed, 10 Jan 2007 21:32:15 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 10, 7 06:52:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > > The proposal can provide a relatively simple mechanism to > authenticate events, such as agreements, conducted over a TLS session > and there is no working, off the shelf, alternative solution available > today that works cross platforms. > > Example scenario: > The server side wants to present a some data to the client that the > user has to accept. Such as agreeing to a purchase order. OK, I'll try to make it short: There is absolutely NONE, ZERO, NIL chance that this can be used in customer<->business relationsships in the European Union, because it is incompatible with the EU data protection directive in many ways. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 15:54:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kSB-0007Mg-FE; Wed, 10 Jan 2007 15:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kS8-0007G7-4H for tls@ietf.org; Wed, 10 Jan 2007 15:53:44 -0500 Received: from simmts5-srv.bellnexxia.net ([206.47.199.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4kRl-0006S3-5g for tls@ietf.org; Wed, 10 Jan 2007 15:53:44 -0500 Received: from pbo8f8e10aowa ([65.94.174.216]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070110205317.JOWI4412.simmts5-srv.bellnexxia.net@pbo8f8e10aowa>; Wed, 10 Jan 2007 15:53:17 -0500 Message-ID: <001901c734f9$8dbbe1b0$d8ae5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: , "Stefan Santesson" References: <200701102032.VAA12262@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Wed, 10 Jan 2007 15:54:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org see inserted: ----- Original Message ----- From: "Martin Rex" To: "Stefan Santesson" Cc: Sent: Wednesday, January 10, 2007 3:32 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > Stefan Santesson wrote: > > > > The proposal can provide a relatively simple mechanism to > > authenticate events, such as agreements, conducted over a TLS session > > and there is no working, off the shelf, alternative solution available > > today that works cross platforms. > > > > Example scenario: > > The server side wants to present a some data to the client that the > > user has to accept. Such as agreeing to a purchase order. > > OK, I'll try to make it short: > > There is absolutely NONE, ZERO, NIL chance that this can be used > in customer<->business relationsships in the European Union, because > it is incompatible with the EU data protection directive in many ways. > > -Martin And in US they mostly look at digital signature as a way to strongly authenticate the user and not as a replacement for a written signature. At least in US and at least one big b2b exchange said that they have a simple non-repudiation practice: they make customers (buyers and sellers) to sign the agreement that stipulates that whatever is the record of a transaction in the exchange database that holds as the non-repudable record. (the name witheld due to the NDA). So they have no need for even application level non-repudiation. So as Stefan pointed out the b2b simply uses http today. In my meetings with b2b customers they say that they need performance not digital signatures. Majority of US financial institutions do not even symmetrically encrypt the data on their intranet for want of better performance (and they still meet the audit requirements circa 2003) so even the use for data retention is questionable. b2b exchange customers even want to replace internet with private lines in order to get rid of the latency associated also with inernet security requirements. As ekr pointed out too there is a serious performance penalty that comes with evidence. b2b customers that I have met if they could vote will vote for performance and against performance degrading evidence. --Omirjan > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 16:29:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4l0t-0004Iq-JE; Wed, 10 Jan 2007 16:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4l0s-0004IW-Iy for tls@ietf.org; Wed, 10 Jan 2007 16:29:38 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4l0q-0002wN-8o for tls@ietf.org; Wed, 10 Jan 2007 16:29:38 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 10 Jan 2007 21:29:35 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 10 Jan 2007 21:29:35 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Wed, 10 Jan 2007 21:29:33 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc09nJXaUMxkIYVSVO/0E/w6MaxagABayDg Message-ID: References: from "Stefan Santesson" at Jan 10, 7 06:52:40 pm <200701102032.VAA12262@uw1048.wdf.sap.corp> In-Reply-To: <200701102032.VAA12262@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, I would expect that the reality around this is more dynamic and complex tha= n your statement. But it is an interesting aspect that should not be neglected. I will do my own checks. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 10 januari 2007 12:32 > To: Stefan Santesson > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > Stefan Santesson wrote: > > > > The proposal can provide a relatively simple mechanism to > > authenticate events, such as agreements, conducted over a TLS session > > and there is no working, off the shelf, alternative solution > available > > today that works cross platforms. > > > > Example scenario: > > The server side wants to present a some data to the client that the > > user has to accept. Such as agreeing to a purchase order. > > OK, I'll try to make it short: > > There is absolutely NONE, ZERO, NIL chance that this can be used > in customer<->business relationsships in the European Union, because > it is incompatible with the EU data protection directive in many ways. > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 17:07:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lb7-0006rS-AR; Wed, 10 Jan 2007 17:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lb6-0006rK-7Z for tls@ietf.org; Wed, 10 Jan 2007 17:07:04 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4lb3-00074M-SM for tls@ietf.org; Wed, 10 Jan 2007 17:07:04 -0500 Received: by machshav.com (Postfix, from userid 512) id 4C1B7FB413; Wed, 10 Jan 2007 22:06:57 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 458E8FB3E5; Wed, 10 Jan 2007 22:06:56 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 77AEF765FE4; Wed, 10 Jan 2007 17:06:55 -0500 (EST) Date: Wed, 10 Jan 2007 17:06:55 -0500 From: "Steven M. Bellovin" To: martin.rex@sap.com Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <200701102032.VAA12262@uw1048.wdf.sap.corp> References: <200701102032.VAA12262@uw1048.wdf.sap.corp> Organization: Columbia University X-Mailer: Claws Mail 2.7.0 (GTK+ 2.10.6; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070110220655.77AEF765FE4@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, 10 Jan 2007 21:32:15 +0100 (MET) Martin Rex wrote: > > There is absolutely NONE, ZERO, NIL chance that this can be used > in customer<->business relationsships in the European Union, because > it is incompatible with the EU data protection directive in many ways. > The Danvers doctrine, RFC 1984, and RFC 2804 cut both ways -- the IETF's protocols are supposed to be based on technical merit, not political-layer decisions. It's quite inconsistent to oppose this because it conflicts with one government-layer policy while not opposing, say, unescrowed strong crypto because that conflicted with a different government-layer policy. (Please read my publication list before accusing me of being a stooge for the NSA...) There are two questions: does the proposal have technical merit, and is there enough "market" demand that it's worth the IETF's time. (I think your specific claim could be argued both ways, but in the spirit of what I just said I won't address that issue.) I would have liked a longer -- a much longer -- discussion in the draft of how this facility might be used. For example, I don't see it as particularly useful for https unless and until there are html-level tags that specify when evidence creation should be used. Perhaps the values being uploaded could be surrounded by ... tags? Many people on this list have mentioned the issue of the poor coupling between TLS and application-level semantics; I would like to see suggestions of how to do it. Without that, it's hard to assess either the correctness or the need for this protocol. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 17:36:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4m3L-0005Bb-Vr; Wed, 10 Jan 2007 17:36:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4m3L-0005BN-2e for tls@ietf.org; Wed, 10 Jan 2007 17:36:15 -0500 Received: from bay0-omc2-s40.bay0.hotmail.com ([65.54.246.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4m3J-00009h-Ac for tls@ietf.org; Wed, 10 Jan 2007 17:36:14 -0500 Received: from hotmail.com ([65.55.131.27]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 10 Jan 2007 14:36:13 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jan 2007 14:36:12 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV17.phx.gbl with DAV; Wed, 10 Jan 2007 22:36:11 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <200701102032.VAA12262@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Wed, 10 Jan 2007 14:36:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 10 Jan 2007 22:36:12.0506 (UTC) FILETIME=[BB32CBA0:01C73507] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, I don't why the claim on the EU Directive is true, as TLS Evidence contains a mandatory "opt-in" mechanism. And, I assert, neither of the authors is arguing their case very well in the document or their explanations given this is a transnational audience. > OK, I'll try to make it short: > > There is absolutely NONE, ZERO, NIL chance that this can > be used > in customer<->business relationsships in the European > Union, because > it is incompatible with the EU data protection directive > in many ways. > Despite pro forma optin mechanism compliance, its normal in US practice for US companies to subvert the Euro-intent on such opt in regimes using safe harbor and other procedural tricks : in the US, you will find that as a consumer one cannot connect to one's commodity service provider if you FAIL TO AGREE TO OPT IN to the data retention policy. US practice on "privacy-regime subversion" goes further: the politics of Federal and State governments often manipulate public policy (usually and LEGITIMATELY by funding mandates) so that the insurers inevitably set the audit/practices standards so all providers REQUIRE the retention policy, thus subverting the consumer-protective optin policy intent, set by the EU Directive. but its America! They get to do what they want, too, for their own consumer standards! This is just like today: phone a US health account insurer to discuss a claim, and it will tell you they are recording the call "for quality purposes". You can opt out, and thus the provider will simply drop the call, interdicting "phone" support... Your optin choice! Of course, it's a semantic lie (the "quality" part; its their to collect evidence of your claim fraud...); but this is reality for consumers. If YOU don't drop the call your side, post notification, you have accepted their policy by failing to opt out. The legal presumptions have been set to suit this bias, in the US sphere. And, we just say a manual legal-obligation passing protocol in effect. Could TLS Evidence do the same, for the web-equivalent via https? That is the real question the authors are posing. note, I'm not saying to IETF: don't do TLS-Evidence-type obligation passing protocols: I cant, having proposed them myself in similar forums, and can see great value in instrumenting privacy policy (and other "battle-of-the-terms" negotiations. But, on "wiretapping", we ALL ON THE SAME SIDE, we have to move beyond good/evil level debate over wiretapping/data-retention etc. As US govt policy has clear given ground - by acceding to decent confidentiality channels in standards - we have to reciprocate and thus move the privacy debate on... beyond "sticks and stones" grade name calling debates of the last 20 years. TLS Evidence is broken in terms of SSL architecture; but it can be fixed. The only question is, do we want to, and is it the right timing? For example, should IETF simply wait 2-3 years until the US national id card debate is more settled, first? > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 17:47:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4mDp-000347-Ni; Wed, 10 Jan 2007 17:47:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4mDp-000342-2o for tls@ietf.org; Wed, 10 Jan 2007 17:47:05 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4mDn-0000or-Ja for tls@ietf.org; Wed, 10 Jan 2007 17:47:04 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA13211; Wed, 10 Jan 2007 23:46:49 +0100 (MEZ) From: Martin Rex Message-Id: <200701102246.XAA14180@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: smb@cs.columbia.edu (Steven M. Bellovin) Date: Wed, 10 Jan 2007 23:46:48 +0100 (MET) In-Reply-To: <20070110220655.77AEF765FE4@berkshire.machshav.com> from "Steven M. Bellovin" at Jan 10, 7 05:06:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Steven M. Bellovin wrote: > > On Wed, 10 Jan 2007 21:32:15 +0100 (MET) > Martin Rex wrote: > > > > There is absolutely NONE, ZERO, NIL chance that this can be used > > in customer<->business relationsships in the European Union, because > > it is incompatible with the EU data protection directive in many ways. > > > The Danvers doctrine, RFC 1984, and RFC 2804 cut both ways -- the > IETF's protocols are supposed to be based on technical merit, not > political-layer decisions. It's quite inconsistent to oppose this > because it conflicts with one government-layer policy while not > opposing, say, unescrowed strong crypto because that conflicted with a > different government-layer policy. The EU data protection directive is not like any other "policy". It is there to protect every citizen from inadequate technology that poses a risk to privacy by gathering and storing unecessary personal data without a subjects explicit consent. By requiring high ethical standards, it is a useful quality control of the real merits of a technology as far as privacy and protection of personal data is concerned. It improves privacy in many ways and deters many kinds of wire-tapping. I know that not many countries allow their citizens to enjoy such freedom, but that should not preclude from understanding the obvious merits/benefits if you look at it. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 18:35:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4myL-0007ZD-Bv; Wed, 10 Jan 2007 18:35:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4myK-0007Z8-MC for tls@ietf.org; Wed, 10 Jan 2007 18:35:08 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4myJ-0000Qj-9I for tls@ietf.org; Wed, 10 Jan 2007 18:35:08 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id AAA17071; Thu, 11 Jan 2007 00:34:56 +0100 (MEZ) From: Martin Rex Message-Id: <200701102334.AAA14800@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: home_pw@msn.com Date: Thu, 11 Jan 2007 00:34:56 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 10, 7 02:36:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I know that there is are no (effective) legal safeguards in the US for personal data. This is why I am worried about the TLS Evidence approach. Just because US citizens are entirely unused to enjoying privacy and protection of their private data, doesn't mean that all the rest of the world should not be entitled to such freedom either by ignoring this security aspect when designing technology. home_pw@msn.com wrote: > > Despite pro forma optin mechanism compliance, its normal in > US practice for US companies to subvert the Euro-intent on > such opt in regimes using safe harbor and other procedural > tricks : in the US, you will find that as a consumer one > cannot connect to one's commodity service provider if you > FAIL TO AGREE TO OPT IN to the data retention policy. That's not quite accurate. Several courts in europe have already ruled that the safe harbor trick is ineffective and therefore illegal. Currently, only governments are still playing some tricks, for businesses this approach may easily become a very costly expedition. Many europeans chicken out and do not insist on their privacy, and incredibly many sign "away" the privacy they're entitled to all to easily. But, as indicated, everybody may revoke their agreement at any time, no reason required. This is why there are several safeguards, like the requirement to provide a detailed list of the information that is going to be collected&persisted plus an exact description of the purpose which the consent agreement will authorize. For every additional information and every additional purpose a new explicit agreement/permission must be obtained. The German Telecom lost also the final appeal when the subscriber of an internet flatrate sued them for keeping a record of his DHCP lease (or equivalent) after he disconnects. > > This is just like today: phone a US health account insurer > to discuss a claim, and it will tell you they are recording > the call "for quality purposes". You can opt out, and thus > the provider will simply drop the call, interdicting "phone" > support... Your optin choice! Here, you could easily get a cease-and-desist order with a daily fine for ever further day of non-compliance for such business practices. The courts here take the "voluntary consent aggreement" requirement in the data protection directive very seriously. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 18:48:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nAb-0003Qa-34; Wed, 10 Jan 2007 18:47:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nAZ-0003QU-SD for tls@ietf.org; Wed, 10 Jan 2007 18:47:47 -0500 Received: from bay0-omc1-s16.bay0.hotmail.com ([65.54.246.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4nAY-0002N8-CA for tls@ietf.org; Wed, 10 Jan 2007 18:47:47 -0500 Received: from hotmail.com ([65.55.131.30]) by bay0-omc1-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 10 Jan 2007 15:47:46 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jan 2007 15:47:45 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV20.phx.gbl with DAV; Wed, 10 Jan 2007 23:47:40 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Kemp, David P." , References: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Wed, 10 Jan 2007 15:47:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 10 Jan 2007 23:47:45.0183 (UTC) FILETIME=[B9D552F0:01C73511] X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Come on David; we can do better than this, as (secure) networking engineers. Cookies are not used for session stickyness/persistence in https, or for failover prep, in HA internet data centers doing 1000-2000 simultaneous handshakes for https sessions. In layer 2 switched and layer 3 routed data centers (of which I've built 2, with teamed nics, redundant gateway convergence, deterministic convergence, etc ), it's the SSLv3 session id that is the "cookie" for controlling that path of the fragment through the switches. This is why it the handshake design changed, between SSLv2 and SSLv3 - to allow for early loadbalancers to control the path take by the fragment once it gets out of the layer 3 space into the forwarding path set by the layer 2 STP(s). In military varieties of this, the sessionid sticky state controls which 803.11q vlan paths trunks that fragment can go over, so the convergence characteristics are known during protocol or device failure condition. This allows fixed timing - enforced by the topology of the data center, not by certain hacks like someone stuffed naively put into TLS 1.2. ----- Original Message ----- From: "Kemp, David P." To: Sent: Wednesday, January 10, 2007 7:21 AM Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Like cookies destroyed grandma's trust in the SSL brand? Yet how many web sites still use cookies, and how many browsers allow users an easy way to both disable cookies entirely or selectively, and delete stored cookies entirely or selectively? If cookies are such a trust buster, why are they still used? A: Because they provide a useful capability. Browser support for TLS extensions would be just as much under the user's control as cookies and ciphersuites. This extension doesn't even exist for grandma unless she goes to the trouble of obtaining a client cert - is your grandma that tech-savvy? And even if she can request and install a client cert, there is no stealth involved in that process :-). The purpose of the proposal is to explore options to allow certificate-enabled clients to provide broadcast (1-to-many) persistent authentication without having to install SOA (WS-*) or other signing-capable plugins on the client. It may or may not be architecturally a better choice to do signing through Web Services vs. TLS. But while you're crying crocodile tears over TLS's "reputation" should it ever gain the ability to do digital signatures, save a few for Vista and digital IDs. Consumer-to-provider authentication (as opposed to consumer-to-provider's-TLS-accelerator) is needed, has both benefits and the abuse potential you are worried about, and is happening regardless of whether TLS is extended. Dave -----Original Message----- From: home_pw@msn.com [mailto:home_pw@msn.com] Sent: Tuesday, January 09, 2007 6:42 PM To: Stefan Santesson; martin.rex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< I'm convinced the term "corporate wiretapping" is proper, and that is one that grandma will inevitably associate with the scheme. And, for that reason, we must recognize that we have in our hands the power to destroy consumer trust in the "SSL brandname". Even this debate could be picked up by journalists, today, to SSL's disadvantage. It doesn't take much to destroy trust. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 19:22:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nhU-0002yg-N8; Wed, 10 Jan 2007 19:21:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nhT-0002x5-DZ for tls@ietf.org; Wed, 10 Jan 2007 19:21:47 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4nhE-00008Z-JY for tls@ietf.org; Wed, 10 Jan 2007 19:21:47 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id BAA05561; Thu, 11 Jan 2007 01:21:19 +0100 (MEZ) From: Martin Rex Message-Id: <200701110021.BAA15468@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: smb@cs.columbia.edu (Steven M. Bellovin) Date: Thu, 11 Jan 2007 01:21:18 +0100 (MET) In-Reply-To: <20070110220655.77AEF765FE4@berkshire.machshav.com> from "Steven M. Bellovin" at Jan 10, 7 05:06:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Steven M. Bellovin wrote: > > On Wed, 10 Jan 2007 21:32:15 +0100 (MET) > Martin Rex wrote: > > > > There is absolutely NONE, ZERO, NIL chance that this can be used > > in customer<->business relationsships in the European Union, because > > it is incompatible with the EU data protection directive in many ways. > > > The Danvers doctrine, RFC 1984, and RFC 2804 cut both ways -- the > IETF's protocols are supposed to be based on technical merit, not > political-layer decisions. I fully agree with you. I'm sorry for giving a poor explanation of the technical merits of a design that is conforming with the requirements of the data protection directive. My impression is that there is a significantly different perception of that value/merit. Someone who was born blind has difficulties to imagine what it means to be able to see and therefore doesn't miss it. An adult who looses eyelight due to an accident will miss it badly. I'm in favour of strong crypto, strong privacy and strong protection of personal data. > > (Please read my publication list before accusing me of being a stooge > for the NSA...) Don't worry, Steve. I know some of your publications and have seen and heard you on several meetings/conferences during 1995-2000. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 19:53:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4oBB-0007h3-JP; Wed, 10 Jan 2007 19:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4oBA-0007gy-7g for tls@ietf.org; Wed, 10 Jan 2007 19:52:28 -0500 Received: from bay0-omc3-s24.bay0.hotmail.com ([65.54.246.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4oB8-0006iE-J1 for tls@ietf.org; Wed, 10 Jan 2007 19:52:28 -0500 Received: from hotmail.com ([65.55.131.21]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 10 Jan 2007 16:52:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jan 2007 16:52:25 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV11.phx.gbl with DAV; Thu, 11 Jan 2007 00:52:24 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Kemp, David P." , Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Wed, 10 Jan 2007 16:52:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 00:52:25.0807 (UTC) FILETIME=[C2DD8DF0:01C7351A] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > The purpose of the proposal is to explore options to > allow certificate-enabled clients to provide broadcast > (1-to-many) persistent authentication without having to > install SOA (WS-*) or other signing-capable plugins on > the client. It may or may not be architecturally a better > choice to do signing through Web Services vs. TLS. But > while you're crying crocodile tears over TLS's > "reputation" should it ever gain the ability to do > digital signatures, save a few for Vista and digital IDs. > > Consumer-to-provider authentication (as opposed to > consumer-to-provider's-TLS-accelerator) is needed, > has both benefits and the abuse potential you are > worried about, and is happening regardless of whether > TLS is extended. This is a fascinating interpretation of the purpose of the work item. So, lets explore it. I had personally NOT got ANY of this from the doc/author-disclosures , so far. Right now, it reads as "enforce subpoena on evidence retention". And it says, block connections, if you (once authenticated) are not clearly authorized and conforming to a mutually agreed data retention policy. But let assume its an "exploration"; i.e. it targets an experimental standard status. That I SUPPORT. Why ever would one not? Its for certificate-enabled clients. Well this only includes about >50% of the wifi(*) bindings made in the last 5 years of explosive wifi adoption by consumers...using EAP-TLS/TTLS to generate Russ Housley's TKIP keying material, for RC4 packet encryption of [TLS/TCP] fragments, by a nic/vlan (counter mode with nonce, and CBC-mode mac/mic/moc/muc). Given AEAP is entering TLS1.2, we can see connectionless TLS coming down the pipe (pun), where after 2**64 bytes, the plaintext of the fragment is finally released, post mac verification. That I support. Make the TCB's secured data store rather large, of course, if you are supporting 1000 connections! (1000* 2**64) Said "exploration" is about investigating (I) broadcast, and (II) persistent authentication. Lets take each, one at a time. Broadcast (1:n): ok I didn't get anything from the text that followed, except that its semantics will be ~equivalent to WS-Security. I didn't see any furtherance of the broadcast notion (which is an interesting term, to me). Presumably, given TLS1.2 will accept non-X.509 certs (e.g. SAML2/WS-Fed assertions), TLS Evidence will be an alternative to SAML/WS-Fed . It will keep the control in the network (where, arguably, it belongs). At the same time, if we look at the connectionless TLS fragment that comes with AEAP, perhaps we do have broadcast keying, in the final/connection KDFs? Persistence: Are you claiming this to intend to be an "https-connection-related stickiness mechanism"?I did NOT get this from ANY reading todate. But, its interesting (being clearly about "security engineering", at least). This would be in scope. They could have said that MORE OBVIOUSLY though! Why do I have to work so hard? I'm an awful writer, but these guys are Grade A students! That spec was beautifully written, apart from gross lack of context. Consumer-provider: I'll assume here you are making an allusion to the writer-to-reader concept from the DoD/NSA email world (which started out as something simple: the user agent software needs proof of user (I.e. human) presence, before rendering the de-ciphered confidential blob in the clear on a trusted display). I assume, we are attempting to now take that notion and evolve it...to a connection/session (versus an connectionless email). I'm interested. (I tried years ago, but could not convince you!! to even start thinking that we might go there...) (*) I had one of the earliest UFO-shaped Apple access points, that dialed out on a 33k modem upon 802.11 binding. I went out and got my own NIC, as I was one of the "wrong class" of participant to get one to play with, at an IETF) I could never figure its key management scheme was, so never turned it on! Apparently, I was one of a million grandpas, in this; we all just gave up. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 10 21:20:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4pXk-0006AW-N0; Wed, 10 Jan 2007 21:19:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4pXj-000639-2R for tls@ietf.org; Wed, 10 Jan 2007 21:19:51 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4pXT-0007Bk-TJ for tls@ietf.org; Wed, 10 Jan 2007 21:19:39 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 28CE882A9; Wed, 10 Jan 2007 20:19:35 -0600 (CST) From: "Mark Brown" To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 10 Jan 2007 20:21:10 -0600 Message-ID: <015801c73527$290a0e30$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc1JyixdcQpmN4uRuqXWFQpAmhRMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "'Kemp, David P.'" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, David, I think you already cleared this up for me. Here's my recap: > What is the difference between a "network trace" > and a "wiretap"? An application architecture that stores trace data > does not require modification (hooking) of the protocol. And a > modification to the protocol to transmit digitally signed data changes > neither the confidentiality properties of the protocol nor the > existence of application architectures that store trace data. When I spoke of a wiretap, I meant viewing only what an attacker can see whenever a TLS session passes through the untrusted network -- the TLS packets. In TLS for RSA case, if you possess the server's private key you should be able to revisit all of the handshake messages (recorded, for example, as raw IP packets using a network trace or other "wiretap") and repeat the key derivation and HMAC calculations etc. for that session; so you can get cleartext from a wiretap if and only if you have access to the server's private key. We raised this in the security considerations, 6.2, last paragraph: An alternative cryptographic mechanism is to save the TLS session itself. The negotiated TLS ciphersuite was already used to protect the Application Data messages, and the Handshake Protocol messages contain the keying material necessary to decrypt them if the party retains the private keys and/or pre-shared secrets. What I meant to say earlier is that this approach (above) works well to preserve the TLS Evidence. If you choose this approach (above), call it the "wiretap" TLS persistence model, then the server application has no need to interface with the TLS layer for the purpose of obtaining the TLS Evidence. It can if it wants to. So there exists a scenario where the server application could use an unchanged API (with the TLS layer) and yet TLS Evidence could still be configured, generated and retained (here, by the server's organization). This is a minimal server-app-impact scenario. The point of the Security Considerations in 6.2 is to tell people, "Be careful with your cleartext!" TLS Evidence suggests ways for implementing systems to avoid spoiling the confidentiality of the cleartext. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 07:17:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yr1-0006ks-Ml; Thu, 11 Jan 2007 07:16:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yr0-0006km-Dy for tls@ietf.org; Thu, 11 Jan 2007 07:16:22 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4yqz-0007ZU-1p for tls@ietf.org; Thu, 11 Jan 2007 07:16:22 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id NAA02714; Thu, 11 Jan 2007 13:10:31 +0100 (MEZ) From: Martin Rex Message-Id: <200701111207.NAA25073@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: stefans@microsoft.com (Stefan Santesson) Date: Thu, 11 Jan 2007 13:07:10 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 5, 7 05:34:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > > If we leave the concept of evidence out of scope and leave it to the > lawyers to worry about, is there any technical merits? Well, this amounts to Capture&sign it all the bits and let the lawyers sort it out. and bears some similarity to the concept Shoot 'em all and let God sort 'em out. Think about what this means for a contract between two parties: Instead of using a blank sheet of paper to write down your contract, you take an arbitrary printed multi-page book from the shelf, write the clauses of your contract on the remaining white spots and pages of that book and require the signature on the entire book and feed the result to the lawyers. home_pw@msn.com wrote: > > Consumer-provider: I'll assume here you are making an > allusion to the writer-to-reader concept from the DoD/NSA > email world (which started out as something simple: the user > agent software needs proof of user (I.e. human) presence, > before rendering the de-ciphered confidential blob in the > clear on a trusted display). One of the guidelines of security engineering (according to Google it seems to originate from Mark Twain) goes like this: Put all your eggs in one basket, and WATCH THAT BASKET! The TLS Evidence proposal applied to the above means that you put up additional baskets and distributed eggs on every access. Since the proposal is quite secretive about the specific requirements and usage scenarios leading to this proposal, it is difficult to assess whether adequate enigneering went into the proposed solution to meet the requirements and minimize risk and security impacts/collateral damage. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 07:27:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4z1z-0003WM-IV; Thu, 11 Jan 2007 07:27:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4z1y-0003V1-2h for tls@ietf.org; Thu, 11 Jan 2007 07:27:42 -0500 Received: from mailhost-dr.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4z1v-0001If-Lc for tls@ietf.org; Thu, 11 Jan 2007 07:27:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 238B634C74; Fri, 12 Jan 2007 01:27:35 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26461-18; Fri, 12 Jan 2007 01:27:35 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 0301D3491C; Fri, 12 Jan 2007 01:27:35 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 5CFD3128096; Fri, 12 Jan 2007 01:27:34 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1H4z1z-0005fO-00; Fri, 12 Jan 2007 01:27:43 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 In-Reply-To: <200701111207.NAA25073@uw1048.wdf.sap.corp> Message-Id: Date: Fri, 12 Jan 2007 01:27:43 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: >Stefan Santesson wrote: >> If we leave the concept of evidence out of scope and leave it to the >> lawyers to worry about, is there any technical merits? > >Well, this amounts to > > Capture&sign it all the bits and let the lawyers sort it out. More importantly, what does it give us over "log the transaction in accordance with established business practice and legal precedent"? This whole discussion seems to be following the path of the nonRepudiation bit boondoggle in which a bunch of techies came up with a cool idea that, once lawyers looked at it, was found to be totally meaningless. If you're trying to define a mechanism that has legal standing then you can't leave the lawyers out of it or you'll just end up with another nonRepudiation bit. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 09:38:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H513o-000163-5D; Thu, 11 Jan 2007 09:37:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H513m-00015C-QJ for tls@ietf.org; Thu, 11 Jan 2007 09:37:42 -0500 Received: from simmts12-srv.bellnexxia.net ([206.47.199.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H513k-0000RW-Dm for tls@ietf.org; Thu, 11 Jan 2007 09:37:42 -0500 Received: from pbo8f8e10aowa ([65.94.172.91]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070111143739.GZEQ29497.simmts12-srv.bellnexxia.net@pbo8f8e10aowa>; Thu, 11 Jan 2007 09:37:39 -0500 Message-ID: <001901c7358e$3e6c94c0$5bac5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: , "Kemp, David P." , , References: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 09:39:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org see inserted: ----- Original Message ----- From: To: "Kemp, David P." ; Sent: Wednesday, January 10, 2007 6:47 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > Come on David; we can do better than this, as (secure) > networking engineers. > > Cookies are not used for session stickyness/persistence in > https, or for failover prep, in HA internet data centers > doing 1000-2000 simultaneous handshakes for https sessions. > In layer 2 switched and layer 3 routed data centers (of > which I've built 2, with teamed nics, redundant gateway > convergence, deterministic convergence, etc ), it's the > SSLv3 session id that is the "cookie" for controlling that > path of the fragment through the switches. But what happens when the application session spans multiple session ids? -Omirjan This is why it > the handshake design changed, between SSLv2 and SSLv3 - to > allow for early loadbalancers to control the path take by > the fragment once it gets out of the layer 3 space into the > forwarding path set by the layer 2 STP(s). > > In military varieties of this, the sessionid sticky state > controls which 803.11q vlan paths trunks that fragment can > go over, so the convergence characteristics are known during > protocol or device failure condition. This allows fixed > timing - enforced by the topology of the data center, not > by certain hacks like someone stuffed naively put into TLS > 1.2. > > ----- Original Message ----- > From: "Kemp, David P." > To: > Sent: Wednesday, January 10, 2007 7:21 AM > Subject: RE: [TLS] Please discuss: > draft-housley-evidence-extns-00< > > Like cookies destroyed grandma's trust in the SSL brand? > Yet how many web sites still use cookies, and how many > browsers allow users an easy way to both disable cookies > entirely or selectively, and delete stored cookies > entirely or selectively? If cookies are such > a trust buster, why are they still used? > A: Because they provide a useful capability. > > Browser support for TLS extensions would be just as much > under the user's control as cookies and ciphersuites. > This extension doesn't even exist for grandma unless > she goes to the trouble of obtaining a client cert - > is your grandma that tech-savvy? And even if she can > request and install a client cert, there is no stealth > involved in that process :-). > > The purpose of the proposal is to explore options to > allow certificate-enabled clients to provide broadcast > (1-to-many) persistent authentication without having to > install SOA (WS-*) or other signing-capable plugins on > the client. It may or may not be architecturally a better > choice to do signing through Web Services vs. TLS. But > while you're crying crocodile tears over TLS's > "reputation" should it ever gain the ability to do > digital signatures, save a few for Vista and digital IDs. > > Consumer-to-provider authentication (as opposed to > consumer-to-provider's-TLS-accelerator) is needed, > has both benefits and the abuse potential you are > worried about, and is happening regardless of whether > TLS is extended. > > Dave > > > > -----Original Message----- > From: home_pw@msn.com [mailto:home_pw@msn.com] > Sent: Tuesday, January 09, 2007 6:42 PM > To: Stefan Santesson; martin.rex@sap.com > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: > draft-housley-evidence-extns-00< > > I'm convinced the term "corporate wiretapping" is proper, > and that is one that grandma will inevitably associate with > the scheme. And, for that reason, we must recognize that we > have in our hands the power to destroy consumer trust in the > "SSL brandname". Even this debate could be picked up by > journalists, today, to SSL's disadvantage. It doesn't take > much to destroy trust. > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 09:57:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51Mw-0003HJ-Er; Thu, 11 Jan 2007 09:57:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51Mu-0003Cu-QU for tls@ietf.org; Thu, 11 Jan 2007 09:57:28 -0500 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51Ms-00047f-W9 for tls@ietf.org; Thu, 11 Jan 2007 09:57:28 -0500 Received: from hotmail.com ([65.55.131.18]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 06:57:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 06:57:26 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV8.phx.gbl with DAV; Thu, 11 Jan 2007 14:57:23 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: , "Stefan Santesson" References: <200701111207.NAA25073@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Thu, 11 Jan 2007 06:57:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 14:57:26.0280 (UTC) FILETIME=[CEB3C880:01C73590] X-Spam-Score: 1.3 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Since the proposal is quite secretive about the specific > requirements > and usage scenarios leading to this proposal, it is > difficult to assess > whether adequate enigneering went into the proposed > solution to meet > the requirements and minimize risk and security > impacts/collateral damage. > > > -Martin The document was very much like the document on a PRF pattern, done in collaboration with Eric, which didn’t even pretend to be a complete disclosure! That one said to me: shut up and rubber stamp, аппаратчик! But, there was a commonality of writing style style with TLS Evidence; but only one that is in common with the better levels of American security engineering. And, both reeked of excellence. American writing style for technical English, minimalism of words, extreme binding of word use to concepts, and no explanation (except through the style itself). Good engineers don’t explain, they specify. The first group and last groups of paragraphs of the document are the most revealing, once you infer the underlying security/legal/business doctrines that belie the design reasoning. And Mark revealed the background art he is applying, to be fair to him: a cross of ABA-ISC digital evidence project goals and mandatory integrity levels for some NCTS project routers doing risk compartmentalization (old Biba stuff, presumably). For the former, the motivation seems to be addressing the practices required for the revised rules for Federal evidence (lalala lawyer/CPA land security "controls", "audit", "operational risk management"... doctrine) and for the latter, the motivation is applying multi-level message routing (where he kept referring to EAL6 "functional" assurances and multi-level A-routers whose critical SEFs for this TLS_evidence-enhanced https are implemented using the TCB doctrine). (N.B. it reminds of the $50M that DeloitesTouche spent on trying to work up a similar VAN business concept for their assurance practice, about 1996 trying to get in on the .com boom, inserting :assured: X.400 MTS relays into the flow of business email) So, lets look in more detail. The first group provides 3 assurance building blocks: 1) collect admissible evidence pertaining to a battle-of-the-terms negotiation, 2) apply the accord to control access to communication capabilities, and 3) audit stored/"wiretapped" records of the handshake agrement sand the APDUs within the recording regime of the alert blocks. #3 includes mandatory storage of all the "private" sessionids and ciphersuites, security labels..., Swedish QUALIFIED CERTS with Pseudonyms... and any and all custom record_types used in a second and later full/resumed handshake. Its clearly a BigBreak, from the privacy goal of the (currently) Proposed Standard, that has been unchanged since the SSLv3 I-D submissions. The last group makes it clear that material that was expected to be private, being "confidential" on the wire (because of the bulk ciphering between the T-bridges, or between the MTS/https relays at layer 7) MUST NOW get cleartext stored, SECURELY. it gives the example of just storing the entire SSL (ciphered) stream, presumably with (escrowed) copies of all the asymmetric key used to unwrap it all again, later, during court testing. For Stefan's point, finally, I could see the "TLS Evidence" signature mechanism being an "event signing" mechanism (like is done in vista today on my TPM'ed machine, for all the TPA integrity benefits due to "technical evidence" management). But, does THAT (a) REQUIRE (secure) storage of the SSL stream and the handshakes and (b) hashes of the handshake messages in the signature block? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 10:34:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51wc-0005tz-DQ; Thu, 11 Jan 2007 10:34:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51wa-0005tp-Vn for tls@ietf.org; Thu, 11 Jan 2007 10:34:20 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51wZ-0005it-FZ for tls@ietf.org; Thu, 11 Jan 2007 10:34:20 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 4A6608447; Thu, 11 Jan 2007 09:34:16 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata Date: Thu, 11 Jan 2007 09:35:52 -0600 Message-ID: <015c01c73596$2d61a910$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acc1Gxlo7ZAOVkjhRMGHgHSy+keYrwADDp0Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: "'Kemp, David P.'" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter, > > The purpose of the proposal is to explore options to > > allow certificate-enabled clients to provide broadcast > > (1-to-many) persistent authentication without having to > > install SOA (WS-*) or other signing-capable plugins on > > the client. It may or may not be architecturally a better > > choice to do signing through Web Services vs. TLS. But > > while you're crying crocodile tears over TLS's > > "reputation" should it ever gain the ability to do > > digital signatures, save a few for Vista and digital IDs. > > > > Consumer-to-provider authentication (as opposed to > > consumer-to-provider's-TLS-accelerator) is needed, > > has both benefits and the abuse potential you are > > worried about, and is happening regardless of whether > > TLS is extended. > > This is a fascinating interpretation of the purpose of the > work item. So, lets explore it. I had personally NOT got ANY > of this from the doc/author-disclosures , so far. I can see how TLS Evidence could be used as David suggests in his terse comment about: "(1-to-many) persistent authentication". You're right we haven't talked about this use of TLS Evidence before. One use for the TLS Evidence two-signature approach is to generate integrity-assured data and metadata. Integrity-assured data/metadata is a create-write-once, read-many thing, and could be considered "(1-to-many) persistent authentication". TLS Evidence can be verified by any third party, so if you choose to share it in this way, many could read it. Obviously the choice to share data should be made in light of legal and moral obligations stemming from the data contents. TLS Evidence is content agnostic. But for the case of integrity-assured data/metadata, perhaps it is useful to transmit and share TLS Evidence in addition to persisting it as an audit trail. So far we've really only talked about the audit trail uses (and potential abuses) of TLS Evidence where (presumably) very few should read it. For example, if any of the final recipients are not attached via trusted connection to the TLS server (for example, if any of the recipients are not on the box with the TLS server, or if you just can't trust the connection for some other reason), those recipients might benefit from integrity assurance / proof of origin for the data/metadata that was received. This may be relevant to the TLS accelerator scenario David mentions. In that case an app may feel a little queasy about the client's identity since the app never gets let in on -- and has no recourse to -- the client authentication process. Here's an integrity-assured data and metadata creation scenario. A note for clarity: a sender usually only writes metadata when that sender is also writing data (i.e. sender is writing/sending but not reading/retrieving). In the TLS Evidence two-signature approach, the sender might not be highly assured, but provides a sender's-signature over the data and metadata. The sender's signature supplies provenance data, proving the origin was this particular sender. Additional knowledge of/about the source (via the source's PKC or some other trusted records) may help qualify "who" sent it and "what" is being sent. For example, the PKC or trusted records pertaining to the PKC might indicate the sending machine (physical location, classification level, sensitivity level, hardware and software in use, etc.) and the originating PKC may also imply the sending user (sender's rank, sender's role, sender's authorizations, etc.). Of course the sender could use any digital signature method and achieve the same result as what has been described so far. TLS Evidence might add some convenience. But an assurance transformation in TLS Evidence happens when the sender's transmission is authorized / granted access by the receiver. Obtaining high assurance is the main goal in this scenario. When the receiver performs the act of access control, for example if the receiver uses a separation kernel to enforce mandatory information flow policies, then the receiver's countersignature can add value. Just about any kind of access control works here. The receiver does not have to send/receive "authorizations" here -- it is common for just client authentication results to be sufficient to decide whether to allow or deny access. All of this happens naturally in TLS handshakes; whether you use mutual authentication, TLS Authorizations, etc., the protocol generates fatal alerts if any step fails or loosely speaking, isn't good enough. So naturally in TLS you can't generate TLS Evidence until the handshake completes successfully, which implies that access is allowed and application_data can flow. To the level (only to the level) that the access control / information flow policy enforcement can be trusted, that is the value of the countersignature. For example, if the receiver is subverted, then the receiver's countersignature adds no assurance. Even if the receiver seems likely to be subverted, still the countersignature adds little assurance. If on the other hand the receiver is EAL6 or EAL7, then you have a high degree of confidence that the information flow was authorized. EAL6 or better is what's in view for integrity-assured metadata. The receiving router is never expected to be able to interpret the data or the metadata. Instead the receiver only verifies that current policy allows the sender's requested information flow (access control check) and that the sender's signature is correct. Those verifications are its only job. If verified, then the receiver's signature (aka countersignature) transforms the sender's metadata into integrity-assured metadata; countersignature adds assurance to the metadata and data asserted by the (now) authorized sender-source. So, in the case of a write of data and metadata, you know who wrote it (sender's digital signature and receiver's validation of the computation's correctness) and you know exactly what was said, but now (upon countersignature) you also know that the write was _authorized_ (in a military case, by policy). So it is correct to infer the sender had the authority to create both the data and the metadata. When you have high assurance that sender was authorized to write this data & metadata, and the data & metadata is digitally signed, then no matter what the contents are, a lot of worries about forged data / metadata go away. Doubts may still exist i.e. that this twice-signed stuff may be the perfect preservation of the sender's erroneous misstatements or lies, but it is certainly NOT unauthorized. However, if the sender repeatedly speaks lies, it would be very easy to change the policy for that sender, revoking that sender's authorization. Relying on this natural feedback loop, TLS Evidence purposefully and absolutely separates itself from the task of discerning lies, misstatements, sender's intent, etc. In other words, TLS Evidence NEVER looks into the application data. The two-signature approach follows from other useful security models/methods. You could see the two-signature approach as dual controls. You could call it separation of duties. I have compared its design to John Rushby's 1981 proposal for the "separation kernel" as different from a "security kernel". Lawyers I have spoken to indicate that the two-signature approach seems fair and not biased towards either sender or receiver. All of these are my goals. The point is that in TLS Evidence each signature accomplishes something different, and nothing can be accomplished by only one signature. This is useful when you want to avoid all-powerful keys (if you believe as I do that such keys can be dangerous). The policy question here is, How can we limit and focus what we authorize subjects to "say" so that they are never authorized to "say" stuff that will hurt the policymaking organization? Policy makers should try to put only those sorts of authorizations on the whitelist, and not for example introduce broad, sweeping authorizations that apply to a large group of nearly anonymous subjects. Pinpoint accuracy when building the authorizations whitelist is the preferred policymaking approach. Benefits / Commercial Application Integrity-Assured Metadata (IAM) can be used to label data with a range of classification levels, sensitivity levels, integrity levels, origin and other information and tags. IAM can provide useful and trustworthy metadata to inform personnel and systems, which in turn can improve efficiencies and accuracy. Correctly formulated IAM should be useful outside of the context of the originating system and/or a high assurance intermediary; specifically, IAM should be especially useful to applications and consumers after it has exfiltrated from a secure originating system. IAM may help enable MILS solutions to scale beyond a single processor system. IAM can be assembled into histories to describe who / what / when for access, transmission and processing for an object. IAM is a tagging, sharing, searching, publishing aid that can help enable the data-sharing "post before processing" paradigm proposed in DoD Directive 8320.2. Metadata, including security IAM, is widely applicable to numerous military and commercial systems. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 11:43:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H531B-0007hK-Ug; Thu, 11 Jan 2007 11:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H531A-0007g7-7y for tls@ietf.org; Thu, 11 Jan 2007 11:43:08 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H530r-0005lS-E4 for tls@ietf.org; Thu, 11 Jan 2007 11:43:08 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA02909; Thu, 11 Jan 2007 17:42:29 +0100 (MEZ) From: Martin Rex Message-Id: <200701111642.RAA28793@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 11 Jan 2007 17:42:23 +0100 (MET) In-Reply-To: <015c01c73596$2d61a910$6801a8c0@rps.local> from "Mark Brown" at Jan 11, 7 09:35:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: DPKemp@missi.ncsc.mil, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Thank your for your explanations. I don't understand why this proposal is brought to the IETF. >From what I read, the IETF originally started out with government funding, an a large part came from the department of defense. The IPv4 spec says something like there was a secretive variant of IP(v4) with support for all the esoteric stuff that you are talking about for use in the military and by secretive agencies. The academic and public wasn't bothered with any of this. Today, the IETF is an open international forum and producing standards for use in COTS (commercial of the shelf) software and Open Source, for the masses (private and business use). There is a huge gap between the concepts that you described and the software that we're using today, at home and in the office --it's not even in the same galaxy. I think you should carry this proposal and the concepts back down into the secret cellar where it comes from, and where those guys dwell who believe that they need it, and that they continue playing on their own. They probably need multi-level security in order to contain the evidence why something fucked up, who was responsible and who else knew about it. In the IETF we should try to produce standards for the needs of the general public and remain on a level playing field with e.g. the IETF apps area. For years they have been complaining that IETF security protocols are already to difficult and too complex for them, and there is some truth in it, they are already pretty secure and pretty complex. A chain is only as strong as its weakest link, and the TLS Evidence proposal is such an enormous and heavy link, it is going to rip this chain apart all alone by its own weight. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 12:03:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ky-00038n-6r; Thu, 11 Jan 2007 12:03:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Kx-00038i-LG for tls@ietf.org; Thu, 11 Jan 2007 12:03:35 -0500 Received: from bay0-omc3-s9.bay0.hotmail.com ([65.54.246.209]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53Kv-0003Rg-6u for tls@ietf.org; Thu, 11 Jan 2007 12:03:35 -0500 Received: from hotmail.com ([65.55.131.24]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 09:03:32 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 09:03:32 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV14.phx.gbl with DAV; Thu, 11 Jan 2007 17:03:28 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Kemp, David P." , Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 09:03:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 17:03:32.0572 (UTC) FILETIME=[6C9051C0:01C735A2] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > In military varieties of this, the sessionid sticky state > controls which 803.11q vlan paths trunks that fragment can > go over... Sorry: 802.1Q, above. I was thinking about 802.11i, EAP-TTLS and then AEAP for TLS1.2 fragments going over a connectionless bearer, or TCP (with those 2**64 fragments under the AES-CCM "hold plaintext till the mac verifies" rule!) But, its fascinating to watch SSL evolve for different embodiments, with distinct tunings to each type of engineering. I can finally see what motivates TLS1.2 now. And, it is good. I was wrong to argue against TLS1.2 procedurally, I now see. But, as Martin hinted: one has to read behind the lines too much, to really review the new features of the TLS spec these days. Its almost impossible to do a conventional requirements trace...so that the crypto feature justifies the mechanism, which justifies the service, which responds to the use case, which is appropriate for application sphere X, and the ciphersuites and their modes are appropriate for the implementation assumptions (UNIX thread pools, switched ethernets with PVLANs, NIC/port ASICs etc). Thus is getting ever harder to (a) understand the (implied) rationales, and (b) evaluate the technical proposals _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 12:07:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ox-00054K-9H; Thu, 11 Jan 2007 12:07:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ow-000545-1I for tls@ietf.org; Thu, 11 Jan 2007 12:07:42 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53Ou-00049K-Ha for tls@ietf.org; Thu, 11 Jan 2007 12:07:42 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0BH7dGs020973 for ; Thu, 11 Jan 2007 12:07:39 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 11 Jan 2007 12:07:39 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Jan 2007 12:07:39 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata Date: Thu, 11 Jan 2007 12:07:42 -0500 Message-ID: In-Reply-To: <015c01c73596$2d61a910$6801a8c0@rps.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata Thread-Index: Acc1Gxlo7ZAOVkjhRMGHgHSy+keYrwADDp0QAB1epxA= From: "Kemp, David P." To: X-OriginalArrivalTime: 11 Jan 2007 17:07:39.0187 (UTC) FILETIME=[FF8EC830:01C735A2] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14928003 X-TM-AS-Result: : Yes--7.900100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xMTA0?= =?us-ascii?B?NjItNzAyMDU0LTcwMzQ2OC03MDk0MTUtMTA1MDQwLTcwMTI5Ny03?= =?us-ascii?B?MDE3NDEtNzAxNzQ5LTcwNDY0NS03MDM5NjQtNzA3MjI1LTcwMTU0?= =?us-ascii?B?Mi03MDA5NTUtMTIxNjI4LTEwNjQ3MC03MDA0NzgtNzAyMzg4LTcw?= =?us-ascii?B?Mzg3NS03MDIxMjYtNzAyNzI2LTcwMzU4NS03MDE0NTUtNzEwNzQy?= =?us-ascii?B?LTcwNDk3Ny0xMzkwMTAtNzAyMDcxLTcwNDkyMS03MDA4NDItNzA3?= =?us-ascii?B?Mjg5LTcwMDQ1NC03MDI2NDMtMTIxMTU1LTcwMjM1OC0xMDU3MDAt?= =?us-ascii?B?NzA4NzkyLTcwNTA5Mi03MTEyMzItNzA0MTk1LTExMzIyOC03MDkx?= =?us-ascii?B?NzAtNzAwODY1LTcwNjExMC03MDA3MjYtNzAyMjYwLTcwNDQwNy03?= =?us-ascii?B?MDM3MTItNzA0NDYxLTcwMTQ2MS03MDM5MDctNzAwMDU3LTcwMjg5?= =?us-ascii?B?OC03MDE5MTQtNzAyODk1LTE0ODA1MC0yMDA0MA==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > > [Dave] The purpose of the proposal is to explore options to > > allow certificate-enabled clients to provide broadcast > > (1-to-many) persistent authentication without having to > > install SOA (WS-*) or other signing-capable plugins on > > the client. It may or may not be architecturally a better > > choice to do signing through Web Services vs. TLS. But > > while you're crying crocodile tears over TLS's > > "reputation" should it ever gain the ability to do > > digital signatures, save a few for Vista and digital IDs. > > > > Consumer-to-provider authentication (as opposed to > > consumer-to-provider's-TLS-accelerator) is needed, > > has both benefits and the abuse potential you are > > worried about, and is happening regardless of whether > > TLS is extended. >=20 > [Peter] This is a fascinating interpretation of the purpose of the > work item. So, lets explore it. I had personally NOT got ANY > of this from the doc/author-disclosures , so far.=20 I got it from Page 12 of the I-D: For example, a client may request access to a resource provided by the server, provide sufficient authentication and authorization information grounds to convince the server to grant the requested access, and receive an affirmative response from the server. A record of TLS Handshake protocol messages representing this example may provide a sufficient record of the intent of both the client and the server. I loathe the use of "intent of the client" here because it smacks of NR and lawyers and judges. But if the client generates a request for a particular resource, then the provider of the resource can assume from the mere existence of a request that the client "intends" to perform some function (such as GET) on that resource. The motivation is separation between outward-facing interfaces contained in a DMZ and back-end transaction processors separated from the DMZ by a high assurance content-validating proxy. I'd much rather see "TLS Evidence" called "Authenticated Stream-to-Transaction Conversion" since that is my motivating scenario, but I don't speak for the authors. The "evidence" in this case is not intended to be used by courts or snoopy governments, it is intended for a transaction processor that receives a request and needs to authenticate the original requestor directly rather than accepting the word of a hackable front end contained in a DMZ. "Broadcast" authentication doesn't mean that there are necessarily many recipients of a specific request (although there could be, for load sharing), just that the requestor has no need to know anything (including certificate info) about the provider back-end in order to enable the back end to authenticate the requestor. It's just another way to express the difference between persistent and session-oriented data authentication. Dave _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 12:38:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53sP-0004uh-7d; Thu, 11 Jan 2007 12:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53sN-0004uc-1T for tls@ietf.org; Thu, 11 Jan 2007 12:38:07 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53sL-00019u-PW for tls@ietf.org; Thu, 11 Jan 2007 12:38:07 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0BHc4Gs023174 for ; Thu, 11 Jan 2007 12:38:05 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 11 Jan 2007 12:38:04 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Jan 2007 12:38:04 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 12:38:03 -0500 Message-ID: In-Reply-To: <200701110021.BAA15468@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc1FqeCqLWeeOj+RA+UhRyoIE7CZwAjY+MQ From: "Kemp, David P." To: X-OriginalArrivalTime: 11 Jan 2007 17:38:04.0648 (UTC) FILETIME=[3F9E0680:01C735A7] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14928003 X-TM-AS-Result: : Yes--4.739100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDM1?= =?us-ascii?B?ODktNzEwNDQyLTcwMjM1OC03MDg3OTItMTM5MDA2LTEzOTAxMC03?= =?us-ascii?B?MDAwNzMtNzA2ODkxLTcwNzUwOC03MTAzNzUtNzAwNTk0LTcwMTk3?= =?us-ascii?B?Ni03MDM3ODgtMTg2MTAxLTcwMTkyNy03MDY1OTEtNzAxNDU1LTcw?= =?us-ascii?B?MjA0NC03MDA0NzYtMTQ4MDUwLTIwMDQw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org There is nothing in this draft that conflicts with EU data sharing and retention policies. If those policies require that data be destroyed immediately after use, then implementations of the draft can be designed to do so. -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com]=20 > > I'm in favour of strong crypto, strong privacy and strong protection > of personal data. As am I. I'm also in favor of strong architectural design, since strong crypto provides no protection from weak implementation. When your personal information is stored by a merchant (with your consent), you'd want the strongest possible measures (as described in my previous message) taken to prevent it from being stolen by technically sophisticated attackers, right? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 13:00:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Dk-0000NF-Gh; Thu, 11 Jan 2007 13:00:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Di-0000KM-QH for tls@ietf.org; Thu, 11 Jan 2007 13:00:10 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54Dh-0005BJ-Fc for tls@ietf.org; Thu, 11 Jan 2007 13:00:10 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id F303D8470; Thu, 11 Jan 2007 12:00:07 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Date: Thu, 11 Jan 2007 12:01:38 -0600 Message-ID: <015d01c735aa$8dc8d490$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200701111642.RAA28793@uw1048.wdf.sap.corp> Thread-Index: Acc1n4PCV7naKaJFQKCFza0fus+ruwAAZ//g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Metadata is not esoteric. Nearly every file system and storage format (from file systems to file formats to databases) uses metadata. "Metadata" does include mundane things like file name, path to file, owner/originator/author, last update, access control lists, etc. Metadata is increasingly (has always been?) recognized as useful in COTSs. It is nearly universal that if you move data from one file system or format to another, metadata gets wiped out, then recreated. Just ftp a file. During the ftp, original metadata gets stripped out and lost (though it is often recreated with new values). I'm saying that it could be valuable to share metadata from one system to another, and TLS Evidence could be used to provide assurance for it. For example, party A could create a purchase order for a system. Party B could receive that purchase order and assemble the ordered system from parts. Party B might share TLS Evidence together with party A's purchase order with suppliers C, D, E. The suppliers might find value in being assured that the purchase order originated with A and has not been altered. I see no gap between the concepts I've described and the systems we're using today. I think it's useful to have some assurance for metadata and/or data in a transmission between systems (for example over an untrusted network, which is common when using TLS). Sometimes it's nice to know that the data hasn't changed since you received it. I don't think that's esoteric. The system that creates TLS Evidence's second signature doesn't need to be esoteric either; simple separation (i.e. the fact that the TLS client and server don't have the same private keys) is often sufficient. In a commercial setting, "assurance" is more loosely defined than with the military's EALs. That's fine. If someone uses a "secure" (not "highly assured") TLS implementation to create TLS Evidence, they may be perfectly happy with the level of assurance that the system provides. Regarding the "secret cellar where it comes from," TLS Evidence is not dark; I'm obviously publishing my designs. My personal background is probably irrelevant, but I've never worked for any part of any federal government prior to my involvement on the US Navy contract acknowledged in the I-D. To date I exclusively use COTS and I interact freely on the 'net. RedPhone Security proposed determining "if a low-assurance encryption protocol implementation can feasibly deliver messages while assuring system-wide message integrity," which is not incompatible with an Open Source software protocol implementation. --mark > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: Thursday, January 11, 2007 10:42 AM > To: Mark Brown > Cc: home_pw@msn.com; tls@ietf.org; DPKemp@missi.ncsc.mil > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use > to > > Thank your for your explanations. > > I don't understand why this proposal is brought to the IETF. > > From what I read, the IETF originally started out with government > funding, an a large part came from the department of defense. > The IPv4 spec says something like there was a secretive variant > of IP(v4) with support for all the esoteric stuff that you > are talking about for use in the military and by secretive agencies. > The academic and public wasn't bothered with any of this. > > > Today, the IETF is an open international forum and producing > standards for use in COTS (commercial of the shelf) software and > Open Source, for the masses (private and business use). > > There is a huge gap between the concepts that you described > and the software that we're using today, at home and in the office > --it's not even in the same galaxy. > > > I think you should carry this proposal and the concepts back down > into the secret cellar where it comes from, and where those guys > dwell who believe that they need it, and that they continue > playing on their own. They probably need multi-level security > in order to contain the evidence why something fucked up, who was > responsible and who else knew about it. > > > In the IETF we should try to produce standards for the needs of > the general public and remain on a level playing field with > e.g. the IETF apps area. For years they have been complaining > that IETF security protocols are already to difficult and too > complex for them, and there is some truth in it, they are > already pretty secure and pretty complex. > > > A chain is only as strong as its weakest link, and the TLS Evidence > proposal is such an enormous and heavy link, it is going to rip > this chain apart all alone by its own weight. > > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 13:18:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54VD-0002ja-BU; Thu, 11 Jan 2007 13:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54VC-0002jV-1D for tls@ietf.org; Thu, 11 Jan 2007 13:18:14 -0500 Received: from seamail.amdocs.com ([66.54.212.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54VA-0000Zo-I1 for tls@ietf.org; Thu, 11 Jan 2007 13:18:14 -0500 Received: from SEAMAIL1.corp.amdocs.com (localhost [127.0.0.1]) by seamail.amdocs.com (8.13.8/8.13.8) with ESMTP id l0BIF8tF001108; Thu, 11 Jan 2007 10:15:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SPAM] RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Date: Thu, 11 Jan 2007 10:18:04 -0800 Message-ID: <0275263AA36EE748891F00F36BB9563B015096FD@seamail1.corp.amdocs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SPAM] RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Thread-Index: Acc1n4PCV7naKaJFQKCFza0fus+ruwAAZ//gAAKpwxA= From: "John Bito" To: "Mark Brown" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Metadata is a registered trademark of the Metadata Company. Perhaps you are concerned about data descriptors or attributes that are local or specific to the system that that created the data. I view these as the responsibility of a data description and structuring technology (RDF, XML, XML-Signature); not the transport (TLS). -----Original Message----- From: Mark Brown [mailto:mark@redphonesecurity.com]=20 Sent: Thursday, January 11, 2007 10:02 AM To: martin.rex@sap.com; tls@ietf.org Subject: [SPAM] RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Martin, Metadata is not esoteric. Nearly every file system and storage format (from file systems to file formats to databases) uses metadata. "Metadata" does include mundane things like file name, path to file, owner/originator/author, last update, access control lists, etc. Metadata is increasingly (has always been?) recognized as useful in COTSs. It is nearly universal that if you move data from one file system or format to another, metadata gets wiped out, then recreated. Just ftp a file. During the ftp, original metadata gets stripped out and lost (though it is often recreated with new values). I'm saying that it could be valuable to share metadata from one system to another, and TLS Evidence could be used to provide assurance for it. For example, party A could create a purchase order for a system. Party B could receive that purchase order and assemble the ordered system from parts. Party B might share TLS Evidence together with party A's purchase order with suppliers C, D, E. The suppliers might find value in being assured that the purchase order originated with A and has not been altered. I see no gap between the concepts I've described and the systems we're using today. I think it's useful to have some assurance for metadata and/or data in a transmission between systems (for example over an untrusted network, which is common when using TLS). Sometimes it's nice to know that the data hasn't changed since you received it. I don't think that's esoteric. The system that creates TLS Evidence's second signature doesn't need to be esoteric either; simple separation (i.e. the fact that the TLS client and server don't have the same private keys) is often sufficient. In a commercial setting, "assurance" is more loosely defined than with the military's EALs. That's fine. If someone uses a "secure" (not "highly assured") TLS implementation to create TLS Evidence, they may be perfectly happy with the level of assurance that the system provides. Regarding the "secret cellar where it comes from," TLS Evidence is not dark; I'm obviously publishing my designs. My personal background is probably irrelevant, but I've never worked for any part of any federal government prior to my involvement on the US Navy contract acknowledged in the I-D. To date I exclusively use COTS and I interact freely on the 'net. RedPhone Security proposed determining "if a low-assurance encryption protocol implementation can feasibly deliver messages while assuring system-wide message integrity," which is not incompatible with an Open Source software protocol implementation. =20 --mark > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: Thursday, January 11, 2007 10:42 AM > To: Mark Brown > Cc: home_pw@msn.com; tls@ietf.org; DPKemp@missi.ncsc.mil > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 -=20 > use to >=20 > Thank your for your explanations. >=20 > I don't understand why this proposal is brought to the IETF. >=20 > From what I read, the IETF originally started out with government=20 > funding, an a large part came from the department of defense. > The IPv4 spec says something like there was a secretive variant of=20 > IP(v4) with support for all the esoteric stuff that you are talking=20 > about for use in the military and by secretive agencies. > The academic and public wasn't bothered with any of this. >=20 >=20 > Today, the IETF is an open international forum and producing standards > for use in COTS (commercial of the shelf) software and Open Source,=20 > for the masses (private and business use). >=20 > There is a huge gap between the concepts that you described and the=20 > software that we're using today, at home and in the office --it's not=20 > even in the same galaxy. >=20 >=20 > I think you should carry this proposal and the concepts back down into > the secret cellar where it comes from, and where those guys dwell who=20 > believe that they need it, and that they continue playing on their=20 > own. They probably need multi-level security in order to contain the=20 > evidence why something fucked up, who was responsible and who else=20 > knew about it. >=20 >=20 > In the IETF we should try to produce standards for the needs of the=20 > general public and remain on a level playing field with e.g. the IETF=20 > apps area. For years they have been complaining that IETF security=20 > protocols are already to difficult and too complex for them, and there > is some truth in it, they are already pretty secure and pretty=20 > complex. >=20 >=20 > A chain is only as strong as its weakest link, and the TLS Evidence=20 > proposal is such an enormous and heavy link, it is going to rip this=20 > chain apart all alone by its own weight. >=20 >=20 > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 13:19:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54WA-0003f6-Sp; Thu, 11 Jan 2007 13:19:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54W9-0003f0-R0 for tls@ietf.org; Thu, 11 Jan 2007 13:19:13 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54W8-0000mU-EU for tls@ietf.org; Thu, 11 Jan 2007 13:19:13 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA19371; Thu, 11 Jan 2007 19:19:03 +0100 (MEZ) From: Martin Rex Message-Id: <200701111819.TAA00529@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: batyr@sympatico.ca (Omirjan Batyrbaev) Date: Thu, 11 Jan 2007 19:19:02 +0100 (MET) In-Reply-To: <001901c7358e$3e6c94c0$5bac5e41@pbo8f8e10aowa> from "Omirjan Batyrbaev" at Jan 11, 7 09:39:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 2.3 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: DPKemp@missi.ncsc.mil, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Omirjan Batyrbaev wrote: > > > Come on David; we can do better than this, as (secure) > > networking engineers. > > > > Cookies are not used for session stickyness/persistence in > > https, or for failover prep, in HA internet data centers > > doing 1000-2000 simultaneous handshakes for https sessions. > > In layer 2 switched and layer 3 routed data centers (of > > which I've built 2, with teamed nics, redundant gateway > > convergence, deterministic convergence, etc ), it's the > > SSLv3 session id that is the "cookie" for controlling that > > path of the fragment through the switches. > > But what happens when the application session spans multiple session ids? You loose (or the application looses). The secretive security guys are as narrow-minded about complex application design as some of us are narrow-minded about the need for multi-level security. Someone who thinks at EAL6+ security levels is not used to multi-millions LinesOfCode applications with annual code growth rates around 10% that have a requirement to perform a single "transaction" accross several entirely independent communication channels using independent protocol abstractions crossing different middleware application components, and being protected and (re-)authenticated by different authentication technologies. People like me try to provide some assurance that all those seperate communication streams ending up in the the same Application backend server are protected and securely authenticated and in fact belong to the same application session on the frontend so that they can all have access to the same shared session state in the backend. Personally, I don't like such complex application design, but it's not that anyone in the apps area would listen to me and cut back on their ambitions. But looking at the other TLS extension in TLS v1.2, it seems the amount of different authentication technologies is going straight up rather than settling down on a single common scheme. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 13:33:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54jk-0001h7-GO; Thu, 11 Jan 2007 13:33:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54ji-0001gR-J0 for tls@ietf.org; Thu, 11 Jan 2007 13:33:14 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H54jh-0005j8-6f for tls@ietf.org; Thu, 11 Jan 2007 13:33:14 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 11 Jan 2007 18:33:11 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Jan 2007 18:33:10 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Thu, 11 Jan 2007 18:33:08 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc09nJXaUMxkIYVSVO/0E/w6MaxagAtzMeg Message-ID: References: from "Stefan Santesson" at Jan 10, 7 06:52:40 pm <200701102032.VAA12262@uw1048.wdf.sap.corp> In-Reply-To: <200701102032.VAA12262@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > OK, I'll try to make it short: > > There is absolutely NONE, ZERO, NIL chance that this can be used > in customer<->business relationsships in the European Union, because > it is incompatible with the EU data protection directive in many ways. > > -Martin Martin, Could you elaborate in what ways this would be incompatible with the EU dat= a protection directive? I went over this with one of the leading Lawyers in Sweden on electronic si= gnature implementations within the EU directives and we could not identify = any significant problems. He could see no problem with recording data during a session and save it as= an audit record. Signed or not. If there would be an issue (due to collection of personal data from the cer= tificate etc), it could be solved by an agreement between the customer and = the merchant or alternatively between the certificate holder and the CA. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 14:15:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55NX-0001hh-Ch; Thu, 11 Jan 2007 14:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55NW-0001ha-Id for tls@ietf.org; Thu, 11 Jan 2007 14:14:22 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55NU-00074X-VF for tls@ietf.org; Thu, 11 Jan 2007 14:14:22 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA07120; Thu, 11 Jan 2007 20:08:27 +0100 (MEZ) From: Martin Rex Message-Id: <200701111908.UAA01228@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 11 Jan 2007 20:08:17 +0100 (MET) In-Reply-To: <015d01c735aa$8dc8d490$6801a8c0@rps.local> from "Mark Brown" at Jan 11, 7 12:01:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > I'm saying that it could be valuable to > share metadata from one system to another, and TLS Evidence could be used to > provide assurance for it. For example, party A could create a purchase > order for a system. Party B could receive that purchase order and assemble > the ordered system from parts. Party B might share TLS Evidence together > with party A's purchase order with suppliers C, D, E. The suppliers might > find value in being assured that the purchase order originated with A and > has not been altered. This example is full of flawed assumptions. One the one hand, you keep on insisting that TLS Evidence is data agnostic, meaning that it can at most verify signatures but has no clue whatsoever about the data. So any assurance is entirely derived from assurance levels of the participating software on either end combined with the policy tied to the signing certs on the assumption these are only issued to highly assured software. So the assurance level that you can get is at most as high as the lowest assurance level of all of the software components involved in the process on both communication peers. Which means that in theory you might get to EAL4, but you're unlikely to find that in any real-world use. TLS is a complex, expensive and completely unnecessary bell&whistle that will result in massive collateral damage when used and I haven't heard of any plausible usage scenario so far, and I can not think of one either. A well engineered approach would not use a shotgun approach to security, but instead a tailored design that meets exactly the needs of the application, can be used for programmatically checking consistency an can create digital tamper-resistant proofs of transactions that contain all and only the necessary information that is necessary -- in which case it will be possible make it conforming with individual, case-specific legal and buisiness requirements. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 14:33:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55fj-0003rw-L8; Thu, 11 Jan 2007 14:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55fi-0003rq-I1 for tls@ietf.org; Thu, 11 Jan 2007 14:33:10 -0500 Received: from bay0-omc2-s38.bay0.hotmail.com ([65.54.246.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55fg-0003mp-10 for tls@ietf.org; Thu, 11 Jan 2007 14:33:10 -0500 Received: from hotmail.com ([65.55.131.23]) by bay0-omc2-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 11:33:07 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 11:33:07 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV13.phx.gbl with DAV; Thu, 11 Jan 2007 19:33:02 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Omirjan Batyrbaev" References: <200701102032.VAA12262@uw1048.wdf.sap.corp> <001901c734f9$8dbbe1b0$d8ae5e41@pbo8f8e10aowa> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 11:33:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 19:33:07.0314 (UTC) FILETIME=[51ED4520:01C735B7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I've lost track of the URL, but somewhere on an MSN/Microsoft site it once had a click-signature mechanism. "Click the Agree button" to be legally bound to something, over the SSL channel. That is not particularly remarkable, of course. However, there was specific and remarkable legal blurb justifying this as an "electronic signature". I recall reading it, wide-eyed. One can gauge the trustworthiness of that "https signature" based on classical evaluation analysis (a) was the https implementation/ciphersuite/CA good enough (b) was the HTML rendered in Microsoft's IE product c) Is the browser and OS assured to ensure nothing else on the PC could interfere with the rendering of the server's-page ...and its dynamic button and event generation/communication. Absent an NCSC evaluation report thereto, the only party that can argue one way or the other is of course the vendor - which just happened to be Microsoft of course. So, I think this was an edge case, that only an MSN site can make this claim for a click signature, because it has complete control over the trusted technology being applied (being an arm of Microsoft, the product maker of IE, https, MSN Servers, etc). However, to be an electronic signature, there has to be a recordation act. Presumably, the MSN audit logs have the details of the ciphersuite used, the browser headers, and perhaps even the SSL session pdus for replay. ----- Original Message ----- From: "Omirjan Batyrbaev" To: ; "Stefan Santesson" Cc: Sent: Wednesday, January 10, 2007 12:54 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< At > least in US and at least one big b2b exchange said that > they have a simple > non-repudiation practice: they make customers (buyers and > sellers) to sign > the agreement that stipulates that whatever is the record > of a transaction > in the exchange database that holds as the non-repudable > record. (the name > witheld due to the NDA). So they have no need for even > application level > non-repudiation. So as Stefan pointed out the b2b simply > uses http today. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 14:39:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55ls-0008TJ-2j; Thu, 11 Jan 2007 14:39:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55lq-0008TB-RE for tls@ietf.org; Thu, 11 Jan 2007 14:39:30 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55ln-0005KK-Qg for tls@ietf.org; Thu, 11 Jan 2007 14:39:30 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 11 Jan 2007 19:39:26 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Thu, 11 Jan 2007 19:39:25 +0000 From: Stefan Santesson To: "martin.rex@sap.com" , Mark Brown Date: Thu, 11 Jan 2007 19:39:24 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Thread-Index: Acc1tP+dcoAzNarxQ1iYDP01JCX1BQAAeKMw Message-ID: References: <015d01c735aa$8dc8d490$6801a8c0@rps.local> from "Mark Brown" at Jan 11, 7 12:01:38 pm <200701111908.UAA01228@uw1048.wdf.sap.corp> In-Reply-To: <200701111908.UAA01228@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > A well engineered approach would not use a shotgun approach to > security, but instead a tailored design that meets exactly > the needs of the application, can be used for programmatically > checking consistency an can create digital tamper-resistant > proofs of transactions that contain all and only the necessary > information that is necessary -- in which case it will be > possible make it conforming with individual, case-specific > legal and buisiness requirements. > Yes, don't we all wish we had that. Especially that we could agree on what = "all and only the necessary information that is necessary" is. Another 10 years will pass before we get there unfortunately. In the meanwh= ile we will continue to conduct business based on passwords and totally spo= ofable security. In security, perfect has always been the enemy of the good= . Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 15:11:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56G7-0001Gf-Ik; Thu, 11 Jan 2007 15:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56G6-0001GU-6P for tls@ietf.org; Thu, 11 Jan 2007 15:10:46 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56G1-0005Ym-Os for tls@ietf.org; Thu, 11 Jan 2007 15:10:46 -0500 Received: by machshav.com (Postfix, from userid 512) id 0A21EFB475; Thu, 11 Jan 2007 20:10:37 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 046DBFB473; Thu, 11 Jan 2007 20:10:36 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 65AEC765FE8; Thu, 11 Jan 2007 15:10:34 -0500 (EST) Date: Thu, 11 Jan 2007 15:10:31 -0500 From: "Steven M. Bellovin" To: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: References: <200701102032.VAA12262@uw1048.wdf.sap.corp> <001901c734f9$8dbbe1b0$d8ae5e41@pbo8f8e10aowa> Organization: Columbia University X-Mailer: Claws Mail 2.7.0 (GTK+ 2.10.6; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070111201034.65AEC765FE8@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, 11 Jan 2007 11:33:01 -0800 wrote: > I've lost track of the URL, but somewhere on an MSN/Microsoft site it > once had a click-signature mechanism. "Click the Agree button" to be > legally bound to something, over the SSL channel. That is not > particularly remarkable, of course. However, there was specific and > remarkable legal blurb justifying this as an "electronic signature". > I recall reading it, wide-eyed. > > One can gauge the trustworthiness of that "https signature" based on > classical evaluation analysis (a) was the https > implementation/ciphersuite/CA good enough (b) was the HTML rendered > in Microsoft's IE product c) Is the browser and OS assured to ensure > nothing else on the PC could interfere with the rendering of the > server's-page ...and its dynamic button and event > generation/communication. Absent an NCSC evaluation report thereto, > the only party that can argue one way or the other is of course the > vendor - which just happened to be Microsoft of course. > > So, I think this was an edge case, that only an MSN site can make > this claim for a click signature, because it has complete control > over the trusted technology being applied (being an arm of Microsoft, > the product maker of IE, https, MSN Servers, etc). However, to be an > electronic signature, there has to be a recordation act. Presumably, > the MSN audit logs have the details of the ciphersuite used, the > browser headers, and perhaps even the SSL session pdus for replay. > You've swallowed the "digital" signature Kool-Aid. What you saw was quite in conformance with the (U.S.) Electronic Signatures Act of 2000. See, for example: http://www.ftc.gov/os/2001/06/esign7.htm http://www.techlawjournal.com/internet/20000703.htm Briefly, the legal notion of a signature has little relationship to what computer people call a digital signature. The (U.S.) courts have held that computer-printed signatures on pieces of paper are legally binding. Sure, such paper -- or such mouse clicks -- can be forged, and there isn't the technical attribute of non-repudiation. If it comes to a court fight, you can make that argument. You can also make the argument that a digital signature was forged because your key was stolen or your machine was hacked. In any event, your analysis and conclusions are wrong. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 15:39:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56go-00007h-66; Thu, 11 Jan 2007 15:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56gm-00006m-6R for tls@ietf.org; Thu, 11 Jan 2007 15:38:20 -0500 Received: from bay0-omc3-s37.bay0.hotmail.com ([65.54.246.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56gL-0005WV-6x for tls@ietf.org; Thu, 11 Jan 2007 15:37:55 -0500 Received: from hotmail.com ([65.55.131.18]) by bay0-omc3-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 12:37:48 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 12:37:48 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV8.phx.gbl with DAV; Thu, 11 Jan 2007 20:37:45 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Mark Brown" , References: <015c01c73596$2d61a910$6801a8c0@rps.local> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata Date: Thu, 11 Jan 2007 12:37:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 20:37:48.0142 (UTC) FILETIME=[5B14A0E0:01C735C0] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "'Kemp, David P.'" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org If it's the intent to solve the problem mentioned, this was not stated in the document. Not even a hint! What I am hearing is that its intended that TLS does more than name a communication port, open it, and secure record flow over the wire; it will henceforth address the Proof problems (PoO, PoS PoD, PoR) for (opaque) information objects by linking signatures flowing over the read and write channels. If the un-definable NR conditions are satisfied when asserting a X.509 bit flag called NR, one can even assert it has PoXwithNR semantics. A (signed) SAML assertion might accompany the signature, to enable mechanism-specific authorization functions (like dual signing is required, no signing on holy days, signature-capture required, the officer's secretary can generate delivery - but not read - receipts). Specifically, its intended to address the SSL offloading pattern in data centers, where loadbalancers often strip SSL in the aggregation layer of the data center, before delivering http payload to the access layer of the server farm (or one of its colos). Thus TLS Evidence also addresses engineering issues to do with (I) managing sticky TLS sessions so TLS fragments and/or cleartext fragments/records are forwarded appropriate through the switches (II) establishing the assurance of particular SSL deployment models in data center configurations (c) complex cases of a hypermedia application multiple managing parallel session/connections, the impact on whom TLS Evidence will now consider in detail. I'm supportive of ALL this, to the level of experiment. I don't think it will be long before we have reinvented the CCITT X.400 1988 security model ("mostly trust the messaging relays, dummy!" )... but lets see where it goes, and how it differs. Whereas with secure X.400 one attached the semantics of the generic signing mechanisms by defining yet another toolkit service APDU to the trusted MTS transport/relaying protocol, in TLS Evidence this will be signaled by cert extension values that signal the service intended for a given "TLS Evidence". And, again like X.400's MTS-based security model, multiple signatures/evidences might be involved to implement a bidirectional assurance such as PoR (which builds upon the PoD signature attached by the loadbalancer, to become a PoR signature/evidence created by the TLS endpoint identified by the full https URI) I think this has to both an https.next and SSL effort tho. And, https is woefully underspecified as to the core, layer 7 security model that is shared widely amongst the many usage model out there. But ,there is plenty of expertise in trusted messaging relay security models. We can draw upon this, to flesh out https properly, particularly if its URIs and connection practices are going to be a critical component of the TLS Evidence semantics. I would see some backlash tho, from certain IETF quarters: it could get political quickly; a lot of ego is involved, here. It WOULD BE quite amusing if, via SSL/TLS and TLS Evidence, the MTS trust model wins out over the writer-to-reader model of S/MIME (and its predecessors). ----- Original Message ----- From: "Mark Brown" To: ; Cc: "'Kemp, David P.'" Sent: Thursday, January 11, 2007 7:35 AM Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata > Peter, > I can see how TLS Evidence could be used as David suggests in his terse > comment about: "(1-to-many) persistent authentication". > You're right we > haven't talked about this use of TLS Evidence before. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 15:43:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56lX-0003Nv-EC; Thu, 11 Jan 2007 15:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56lV-0003Nq-Mt for tls@ietf.org; Thu, 11 Jan 2007 15:43:13 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56lU-0006pr-6V for tls@ietf.org; Thu, 11 Jan 2007 15:43:13 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA22555; Thu, 11 Jan 2007 21:43:01 +0100 (MEZ) From: Martin Rex Message-Id: <200701112043.VAA02623@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: stefans@microsoft.com (Stefan Santesson) Date: Thu, 11 Jan 2007 21:43:02 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 11, 7 06:33:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > > Could you elaborate in what ways this would be incompatible with > the EU data protection directive? I already gave two examples. I need to point out that the EU directive is a framework with some wiggle room for national governments in making laws that are being used in court. I'm familiar only with the German incarnation of the data protection directive. I actually used the wrong URL last time (the telecommunications subset) the data protection act appears to be this one: http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html > > I went over this with one of the leading Lawyers in Sweden on > electronic signature implementations within the EU directives > and we could not identify any significant problems. I'll try to give you some guidance, but IANAL. I draw my conclusions from (German) court decisions, mainly those that were decided by appeals or supreme court. See definitions for "personal data" (Art 2a), "processing" (Art 2b), etc. The problems arise from the fact that by signing the raw communication data, the business is almost always going to "capture" information that is unnecessary for the intended (business) purpose (see Art 6 a,b,c) and quite possibly information which the business doesn't know ahead of time, however a business is required to obtain a **VOLUNTARY** explicit and individual consent agreement listing the exact information that is to be processed, exact purpose of processing While some specific data might be vital for a business purpose or transaction, a blanket capture at the network level is very likely to result in capturing of unnecessary data. Removing the unnecessary data after the capture might likely be difficult, because it will invalidate the digital signatures on the rest (and once they're invalid, it turns out it was a real waste to create them in the first place). The data protection directive requires the business to take efforts to not collect unecessary data (Art. 2 a,b,c) in the first place, and to delete every piece of information when it is no longer necessary. A broken protocol design that makes vital information inseperable from unnecessary or no longer necessary information (because of a digital signature that would be no longer verifiable) is no valid excuse for not deleting it. E.g. there is no necessity to persist a User-Agent: or HTTP-Refer: from a HTTP GET request, so if that information is not deleted when the online session ends, it is a violation of the data protection directive. As I mentioned before, the German supreme court made a final decision about 2 months ago that it is(was) illegal to keep a record of the equivalent of a DHCP-Lease for an internet DSL-flatrate customer (IP+customer+start-time+end-time) after the customer hangs up. (and the only reason why (only) phone companies will be able to keep this record in the future is a recently enacted legislation, but that is about very specific information and network/phone operators and providers only). I expect there will be a lot of gobbledigoo in an TLS Evidence capture which MUST be deleted when the session ends. Even if the business is able to obtain the purely volutary, and formally correct consent agreement from his customer for keeping all gorily detailed unnecessary information, not providing a capability to delete the unnecessary data upon request would amount to a violation of the data protection act. Want to put a TLS Evidence persising business out of business? Sign up, purchase, check your http-watch what crap they captured which they aren't entitled to. It wouldn't be suprising if they actually failed to obtain a valid consent agreement. But even if they do ... wait 2 weeks, request a detailed status report of what data they (admit to) store (Art 12), revoke consent for all unnecessary data, go to court and they'll likely have to massively purge "TLS evidence" and/or junk their software or go out of business. Btw. if a business fails to list a piece of information that it intends to process or an intended purpose in the consent agreement, then the content agreement will be invalid in its entirety! > > He could see no problem with recording data during a session and > save it as an audit record. Signed or not. > > If there would be an issue (due to collection of personal data > from the certificate etc), it could be solved by an agreement > between the customer and the merchant or alternatively between > the certificate holder and the CA. No, that will be generally insufficient. Other than what is common abusive practice in the US, the courts here in Germany are _dead_serious_ about (a) businesses avoiding to collect unecessary data, (b) consent agreements being accurate about the exact information and purpose, (c) every piece of information being deleted when it is no longer necessary (and not when it seems fit) and (d) the consent agreement being purely voluntary (no pressure of any kind) and revokable at any time. Consumer protection associations will be able to get cease-and-desist orders against companies persisting TLS Evidence that includes unnecessary data or data for which no valid consent agreement is obtained or where they do not or can not delete unnecessary data. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 15:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56sD-0005qZ-2E; Thu, 11 Jan 2007 15:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56s7-0005nn-6C for tls@ietf.org; Thu, 11 Jan 2007 15:50:03 -0500 Received: from bay0-omc3-s16.bay0.hotmail.com ([65.54.246.216]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56s5-0007rf-RN for tls@ietf.org; Thu, 11 Jan 2007 15:50:03 -0500 Received: from hotmail.com ([65.55.131.26]) by bay0-omc3-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 12:50:01 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 12:50:01 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV16.phx.gbl with DAV; Thu, 11 Jan 2007 20:49:56 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Steven M. Bellovin" References: <200701102032.VAA12262@uw1048.wdf.sap.corp><001901c734f9$8dbbe1b0$d8ae5e41@pbo8f8e10aowa> <20070111201034.65AEC765FE8@berkshire.machshav.com> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 12:49:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 20:50:01.0190 (UTC) FILETIME=[1002E060:01C735C2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > On Thu, 11 Jan 2007 11:33:01 -0800 > wrote: > >> I've lost track of the URL, but somewhere on an >> MSN/Microsoft site it >> once had a click-signature mechanism. "Click the Agree >> button" to be >> legally bound to something, over the SSL channel. That is >> not >> particularly remarkable, of course. However, there was >> specific and >> remarkable legal blurb justifying this as an "electronic >> signature". >> I recall reading it, wide-eyed. > Sure, such paper -- or such mouse clicks -- can be forged, > and there > isn't the technical attribute of non-repudiation. If it > comes to a > court fight, you can make that argument. You can also > make the > argument that a digital signature was forged because your > key was > stolen or your machine was hacked. > > In any event, your analysis and conclusions are wrong. I thought I was commenting on the fact that (a) it claimed the click to be an electronic signature (versus a clickthru _agreement_) (b) it's a click over SSL (c) whats intesting is that the recordation requirement of ESIGN can only be being satisfied using an SSL audit trail (which is germane to the TLS Evidence work item proposal analysis) Im perfectly well aware that a digital signature is but one kind of electronic signature under ESIGN laws. I was wide eyed about the claim that it satisfied the legal definition of electronic signature (in the public law). Normally, folks allude to other legal bases, common practice about agreement formulation ,etc. This was SPECIFIC to be claiming to satisfy the rules under ESIGN. You don't see this, very often. http://www.ftc.gov/os/2001/06/esign7.htm > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 16:04:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H575W-0001bv-3d; Thu, 11 Jan 2007 16:03:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H575V-0001bi-5F for tls@ietf.org; Thu, 11 Jan 2007 16:03:53 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H575M-0002uj-Uw for tls@ietf.org; Thu, 11 Jan 2007 16:03:53 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA29169; Thu, 11 Jan 2007 22:03:26 +0100 (MEZ) From: Martin Rex Message-Id: <200701112103.WAA03004@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to To: stefans@microsoft.com (Stefan Santesson) Date: Thu, 11 Jan 2007 22:03:26 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Jan 11, 7 07:39:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > Martin Rex wrote: > > A well engineered approach would not use a shotgun approach to > > security, but instead a tailored design that meets exactly > > the needs of the application, can be used for programmatically > > checking consistency an can create digital tamper-resistant > > proofs of transactions that contain all and only the necessary > > information that is necessary > > Yes, don't we all wish we had that. Especially that we could agree on > what "all and only the necessary information that is necessary" is. You got me wrong. > > -- in which case it will be > > possible make it conforming with individual, case-specific > > legal and buisiness requirements. Instead of having to redesign and rewrite the entire application protocol stack for every use case in order to accomodate what data will and will not become part of the TLS Evidence, one can make it a configuration option for the customer in the application. So all of the attributes that the backend wants to get signed will be tagged as such in the request from the backend to the frontend. Auxiliary information will go untagged and not be included in the signature. Because the app knows what it wants signed, it can actually verify that it receives what it is looking for. > > Another 10 years will pass before we get there unfortunately. > In the meanwhile we will continue to conduct business based on > passwords and totally spoofable security. A data-agnostic TLS-Evidence is still spoofable because of a lack of assurance of the participating software components. > > In security, perfect has always been the enemy of the good. Perfect forward secrecy is an enemy of TLS Evidence, and I prefer the former by a significant margin. (I mean Perfect Forward Secrecy as a design goal of the entire system, not only as an isolated characteristic in the threat model for a particular network link). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 16:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57ow-0003xj-UL; Thu, 11 Jan 2007 16:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57ov-0003xS-AV for tls@ietf.org; Thu, 11 Jan 2007 16:50:49 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57os-0006KC-U5 for tls@ietf.org; Thu, 11 Jan 2007 16:50:49 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA07260; Thu, 11 Jan 2007 22:50:38 +0100 (MEZ) From: Martin Rex Message-Id: <200701112150.WAA03789@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to To: mark@redphonesecurity.com (Mark Brown) Date: Thu, 11 Jan 2007 22:50:38 +0100 (MET) In-Reply-To: <015c01c73596$2d61a910$6801a8c0@rps.local> from "Mark Brown" at Jan 11, 7 09:35:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: DPKemp@missi.ncsc.mil, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Obviously the choice to share data should be made in light of legal and > moral obligations stemming from the data contents. TLS Evidence is content > agnostic. But for the case of integrity-assured data/metadata, perhaps it > is useful to transmit and share TLS Evidence in addition to persisting it as > an audit trail. So far we've really only talked about the audit trail uses > (and potential abuses) of TLS Evidence where (presumably) very few should > read it. > > For example, if any of the final recipients are not attached via trusted > connection to the TLS server (for example, if any of the recipients are not > on the box with the TLS server, or if you just can't trust the connection > for some other reason), those recipients might benefit from integrity > assurance / proof of origin for the data/metadata that was received. This > may be relevant to the TLS accelerator scenario David mentions. In that > case an app may feel a little queasy about the client's identity since the > app never gets let in on -- and has no recourse to -- the client > authentication process. Now I'm slighlty confused about how that should work. As you said, TLS Evidence is content agnostic, and covers the raw datastream plus the TLS handshake. What the application is going to receive is only a fraction of the stuff that was signed and various middleware layers in between will have likely aggregated, reformatted, canonicalized, modified, stripped protocol layers and converted to local character set before the application gets its hands on the request data. So in general, even if the application jumps hoops to retrieve the raw TLS evidence, it can only perform a consistency check on the opaque blob checking the signature, it will usually have zero chance to verify that the request it has received through the regular protocol stack really matches to what is scattered somewhere with in the opaque TLS Evidence blob. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 17:20:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58HL-0006aP-07; Thu, 11 Jan 2007 17:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58HJ-0006aE-I6 for tls@ietf.org; Thu, 11 Jan 2007 17:20:09 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58HH-0005Zs-9K for tls@ietf.org; Thu, 11 Jan 2007 17:20:09 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0BMK4Gs012532 for ; Thu, 11 Jan 2007 17:20:04 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 11 Jan 2007 17:20:04 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Jan 2007 17:20:04 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Date: Thu, 11 Jan 2007 17:20:03 -0500 Message-ID: In-reply-to: <200701112103.WAA03004@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to Thread-Index: Acc1xBWnsPUE/8FASISg4OATp6OduAABe6ZQ From: "Kemp, David P." To: X-OriginalArrivalTime: 11 Jan 2007 22:20:04.0666 (UTC) FILETIME=[A4BBE1A0:01C735CE] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14930000 X-TM-AS-Result: : Yes--7.339800-0-2-1 X-TM-AS-Category-Info: : 2:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xMzkw?= =?us-ascii?B?MDYtNzAwMDczLTEzOTAxMC03MDMzNjYtNzAyNzI2LTcwMTYxOC03?= =?us-ascii?B?MDE3MzgtNzA0MDM0LTcwMjcxNS03MDE4MjctNzA4NjM0LTcwMDgz?= =?us-ascii?B?My03MDIxMzEtNzAxNDU1LTEwNjIzMC03MDEzMDUtMTIxMTU1LTcw?= =?us-ascii?B?MTIyMC03MDIxNTAtNzAwOTc1LTcwMzMzNC03MTAzNzUtNzAzMzY0?= =?us-ascii?B?LTcwNzM2MS03MDM1NDYtNzAzNzg4LTcwMzU4OS03MDE5MjctMTIx?= =?us-ascii?B?NzA5LTcwMzA3Ni03MDQwMzItMTQ4MDUwLTIwMDQw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 >> >> In security, perfect has always been the enemy of the good. > > Perfect forward secrecy is an enemy of TLS Evidence, and > I prefer the former by a significant margin. (I mean Perfect Forward > Secrecy as a design goal of the entire system, not only as > an isolated characteristic in the threat model for a particular > network link). You keep saying that, but please explain why data retained by "network trace" components that log all levels of the protocol stack is not an enemy of perfect forward secrecy. If data is retained, it is retained, regardless of whether a signature exists to authenticate that data. -------------- 6.2. Storage Considerations Parties that choose to preserve a plaintext record of Application Data or Handshake Protocol messages for evidence verification at a later time must ensure must ensure that this data is not inappropriately disclosed by employing suitable physical protection or cryptographic mechanisms that are at least as strong as the selected TLS ciphersuite. --------------- That's true enough, but isn't it just as true that parties that choose to preserve plaintext records of *normal TLS sessions* must apply the same level of protection? When evaluating secrecy as a design goal of the entire system, the same operating policies (what data is stored where and for how long) must be applied to signed evidence and to unsigned evidence, otherwise a comparison between TLS extension and unextended TLS is meaningless. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 17:28:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Oi-0001ox-RJ; Thu, 11 Jan 2007 17:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Og-0001nB-RQ for tls@ietf.org; Thu, 11 Jan 2007 17:27:46 -0500 Received: from bay0-omc2-s36.bay0.hotmail.com ([65.54.246.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58Of-00086K-Bc for tls@ietf.org; Thu, 11 Jan 2007 17:27:46 -0500 Received: from hotmail.com ([65.55.131.18]) by bay0-omc2-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 14:27:44 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 14:27:44 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV8.phx.gbl with DAV; Thu, 11 Jan 2007 22:27:44 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Kemp, David P." , References: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use tocreate integrity-assured metadata Date: Thu, 11 Jan 2007 14:27:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 11 Jan 2007 22:27:44.0709 (UTC) FILETIME=[B6F0DF50:01C735CF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > > Consumer-to-provider authentication (as opposed to > > consumer-to-provider's-TLS-accelerator) is needed, > > has both benefits and the abuse potential you are > > worried about, and is happening regardless of whether > > TLS is extended. [David] I got it from Page 12 of the I-D: For example, a client may request access to a resource provided by the server, provide sufficient authentication and authorization information grounds to convince the server to grant the requested access, and receive an affirmative response from the server. A record of TLS Handshake protocol messages representing this example may provide a sufficient record of the intent of both the client and the server. Wow. you got a lot more out of that paragraph than I did! Obviously the words must have much more loaded meanings that I realized (sufficient, convince, grant, affirm, record, intent). I thought it meant: (i) do a conventional client auth (and accept the TLS evidence extensions), and (ii) a signature comes back saying "you just authenticated to website URI x; we agree that use of this URI is subject to the terms and conditions attached in the signer's cert"). But. Ive clearly learned this is actually all about: 1 intent 2 SSL offloading. Your 1 point does clearly indicate out that the designers are FURTHERMORE making very specific (legalistic) claims about facilitating the signaling (and acceptance of?) intent. Perhaps this is too strong: its an issue that they are focused on, and intend their design to address its nature. IETF would be adopting that as a work item, if TLS Evidence becomes a work item. on point 2: I like the general analytical model your developing tho ...and the problem definition that IETF can certainly address, if it wants. Your essentially asserting that the signature may come from the website, rather than the loadbalancer that is doing SSL offloading, in an increasing number of IDCs. And, the semantics of the signature would involve reliance on a (signing) cert for the app-server - whose X>509 extensions express which Ts&Cs are now binding for that URI, located way back in the server farm. This is all good, and was stock VeriSign design work early on, that never went far, pending adoption of digital signatures for e-commerce. Again, the authors need to cater for grade C students (like me), not only grade A students. It has to be a "bit more" spelled out (e.g. loadbalancer, SSL offloading, consumer-to-provider-vs-loadbalancer). Its ever more interesting, tho., assuming the protocol's hashing of handshakes can be designed not to auto-fall foul of regulations affecting 450 million of the Internet's users. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 17:43:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58d5-0001HA-AX; Thu, 11 Jan 2007 17:42:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58d3-0001BN-5g for tls@ietf.org; Thu, 11 Jan 2007 17:42:37 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58cz-0002vo-V7 for tls@ietf.org; Thu, 11 Jan 2007 17:42:37 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA19971; Thu, 11 Jan 2007 23:42:19 +0100 (MEZ) From: Martin Rex Message-Id: <200701112242.XAA04497@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: home_pw@msn.com Date: Thu, 11 Jan 2007 23:42:18 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 11, 7 06:57:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > The document was very much like the document on a PRF > pattern, done in collaboration with Eric, which didn’t even > pretend to be a complete disclosure! That one said to me: > shut up and rubber stamp. 10 Years ago the IETF was quite resistant to rubber stamping requests (SSLv3, S/Mime), but I have the impression that the folks with the hidden agendas have since significantly improved on their tactics and achieved to blend in with traditional IETF in serveral areas. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 17:45:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58fG-0003iE-T0; Thu, 11 Jan 2007 17:44:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58fG-0003ho-6F for TLS@lists.ietf.org; Thu, 11 Jan 2007 17:44:54 -0500 Received: from simmts8.bellnexxia.net ([206.47.199.166] helo=simmts8-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58fE-0003UH-TC for TLS@lists.ietf.org; Thu, 11 Jan 2007 17:44:54 -0500 Received: from pbo8f8e10aowa ([65.94.172.91]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070111224449.THYK18487.simmts8-srv.bellnexxia.net@pbo8f8e10aowa>; Thu, 11 Jan 2007 17:44:49 -0500 Message-ID: <000701c735d2$4cb800c0$5bac5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: Date: Thu, 11 Jan 2007 17:46:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: billg@microsoft.com Subject: [TLS] On trustworthiness and evidence X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi all, In b2b real-time trading the proposed TLS evidence machine goes against the trustworthiness. It is because the delay of X milliseconds that the evidence mechanism will introduce goes against the trustworthiness of the data since the real time markets move really fast and the transaction data and the transaction workflow has to be really fresh and hard real time to conduct a transaction with trustworthiness. Otherwise the traders has to act on X milliseconds stale data due to the evidence mechanism that they are not asking for (see my previous messages). Please feel free to share this with Bill Gates. --Omirjan Thanks in advance, Regards, Omirjan Batyrbaev, CTO B3 Security Corp. batyr@b3securitycorp.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 17:54:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58oG-00018G-Nz; Thu, 11 Jan 2007 17:54:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58oE-000187-Ru for tls@ietf.org; Thu, 11 Jan 2007 17:54:10 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58oD-0004sL-9p for tls@ietf.org; Thu, 11 Jan 2007 17:54:10 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 11 Jan 2007 22:54:08 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Thu, 11 Jan 2007 22:54:08 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Thu, 11 Jan 2007 22:54:05 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc1wR9tJNLjzxLUR6KmAbzs0i6TtwAENeFw Message-ID: References: from "Stefan Santesson" at Jan 11, 7 06:33:08 pm <200701112043.VAA02623@uw1048.wdf.sap.corp> In-Reply-To: <200701112043.VAA02623@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Thank you for your elaborate answer and references. It would not surprise me though if Germany in this area is more radical tha= n other EU countries, but that does not make your argument invalid. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 11 januari 2007 12:43 > To: Stefan Santesson > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > Stefan Santesson wrote: > > > > Could you elaborate in what ways this would be incompatible with > > the EU data protection directive? > > I already gave two examples. I need to point out that the EU directive > is a framework with some wiggle room for national governments in making > laws that are being used in court. I'm familiar only with the German > incarnation of the data protection directive. > > I actually used the wrong URL last time (the telecommunications subset) > the data protection act appears to be this one: > > http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html > > > > > I went over this with one of the leading Lawyers in Sweden on > > electronic signature implementations within the EU directives > > and we could not identify any significant problems. > > I'll try to give you some guidance, but IANAL. I draw my conclusions > from (German) court decisions, mainly those that were decided by > appeals or supreme court. > > See definitions for "personal data" (Art 2a), "processing" (Art 2b), > etc. > > The problems arise from the fact that by signing the raw communication > data, the business is almost always going to "capture" information > that is unnecessary for the intended (business) purpose (see Art 6 > a,b,c) > and quite possibly information which the business doesn't know ahead of > time, > however a business is required to obtain a **VOLUNTARY** explicit and > individual consent agreement listing the exact information that is to > be > processed, exact purpose of processing > > While some specific data might be vital for a business purpose or > transaction, a blanket capture at the network level is very likely > to result in capturing of unnecessary data. Removing the unnecessary > data after the capture might likely be difficult, because it will > invalidate the digital signatures on the rest (and once they're > invalid, it turns out it was a real waste to create them in the first > place). > > The data protection directive requires the business to take efforts > to not collect unecessary data (Art. 2 a,b,c) in the first place, > and to delete every piece of information when it is no longer > necessary. A broken protocol design that makes vital information > inseperable from unnecessary or no longer necessary information > (because of a digital signature that would be no longer verifiable) > is no valid excuse for not deleting it. > > E.g. there is no necessity to persist a User-Agent: or HTTP-Refer: > from a HTTP GET request, so if that information is not deleted > when the online session ends, it is a violation of the data > protection directive. > > As I mentioned before, the German supreme court made a final decision > about 2 months ago that it is(was) illegal to keep a record of the > equivalent of a DHCP-Lease for an internet DSL-flatrate customer > (IP+customer+start-time+end-time) after the customer hangs up. > (and the only reason why (only) phone companies will be able to keep > this record in the future is a recently enacted legislation, > but that is about very specific information and network/phone > operators and providers only). > > I expect there will be a lot of gobbledigoo in an TLS Evidence > capture which MUST be deleted when the session ends. > > Even if the business is able to obtain the purely volutary, > and formally correct consent agreement from his customer > for keeping all gorily detailed unnecessary information, > not providing a capability to delete the unnecessary data > upon request would amount to a violation of the data > protection act. > > Want to put a TLS Evidence persising business out of business? > Sign up, purchase, check your http-watch what crap they captured > which they aren't entitled to. It wouldn't be suprising if > they actually failed to obtain a valid consent agreement. > But even if they do ... wait 2 weeks, request a detailed > status report of what data they (admit to) store (Art 12), > revoke consent for all unnecessary data, go to court and > they'll likely have to massively purge "TLS evidence" > and/or junk their software or go out of business. > > > Btw. if a business fails to list a piece of information that it > intends to process or an intended purpose in the consent agreement, > then the content agreement will be invalid in its entirety! > > > > > > He could see no problem with recording data during a session and > > save it as an audit record. Signed or not. > > > > If there would be an issue (due to collection of personal data > > from the certificate etc), it could be solved by an agreement > > between the customer and the merchant or alternatively between > > the certificate holder and the CA. > > No, that will be generally insufficient. > > Other than what is common abusive practice in the US, the courts > here in Germany are _dead_serious_ about (a) businesses avoiding > to collect unecessary data, (b) consent agreements being accurate > about the exact information and purpose, (c) every piece of > information being deleted when it is no longer necessary > (and not when it seems fit) and (d) the consent agreement being > purely voluntary (no pressure of any kind) and revokable at any time. > > Consumer protection associations will be able to get cease-and-desist > orders against companies persisting TLS Evidence that includes > unnecessary > data or data for which no valid consent agreement is obtained or where > they do not or can not delete unnecessary data. > > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 18:06:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H590I-0007mu-Sm; Thu, 11 Jan 2007 18:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H590H-0007mo-91 for tls@ietf.org; Thu, 11 Jan 2007 18:06:37 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H590F-00076a-Sy for tls@ietf.org; Thu, 11 Jan 2007 18:06:37 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id AAA12942; Fri, 12 Jan 2007 00:06:31 +0100 (MEZ) From: Martin Rex Message-Id: <200701112306.AAA04887@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Fri, 12 Jan 2007 00:06:30 +0100 (MET) In-Reply-To: from "Kemp, David P." at Jan 11, 7 05:20:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Kemp, David P. wrote: > > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > >> > >> In security, perfect has always been the enemy of the good. > > > > Perfect forward secrecy is an enemy of TLS Evidence, and > > I prefer the former by a significant margin. (I mean Perfect Forward > > Secrecy as a design goal of the entire system, not only as > > an isolated characteristic in the threat model for a particular > > network link). > > You keep saying that, but please explain why data retained by > "network trace" components that log all levels of the protocol > stack is not an enemy of perfect forward secrecy. If data is > retained, it is retained, regardless of whether a signature > exists to authenticate that data. The incentive factor. Creating TLS Evidence has a significant higher cost that persisting it, and as it is somewhere between fully unclear to impossible to interpret the signed contents programmatically, there is a certain likelyhood that someone how goes through the effort to create it will want to persist it. Remember, if it was _just_ about signature verification, you could either use a secure channel bindings approach or just "sign" a secure random challenge, depending on your exact requirements. Although I generally dislike channel bindings, I think they are a much better fit than TLS Evidence (at least for the IETF). If you can get management to approve the cost of having it after having convinced them how useful and valuable digital signatures on the entire communications may turn out to be (e.g. for lawsuits), that management might want that expensive TLS Evidence to be retained/archived. Probably everyone will agree that retaining a full network level trace is most often a waste of resources. Unfortunately, the TLS Evidence blob is an all-or-nothing thingy with the lowest possible signal-noise-ratio. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 18:48:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H59e3-0006s7-5t; Thu, 11 Jan 2007 18:47:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H59e2-0006r4-16 for tls@ietf.org; Thu, 11 Jan 2007 18:47:42 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H59dz-0005EA-Kv for tls@ietf.org; Thu, 11 Jan 2007 18:47:42 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id AAA16838; Fri, 12 Jan 2007 00:47:18 +0100 (MEZ) From: Martin Rex Message-Id: <200701112347.AAA05530@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: ben@layer8.net (Benjamin Black) Date: Fri, 12 Jan 2007 00:47:18 +0100 (MET) In-Reply-To: <45A68B76.9010403@layer8.net> from "Benjamin Black" at Jan 11, 7 11:09:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Benjamin Black wrote: > > i know approximately nothing of EU data protection requirements, but > something about US and payment card industry data protection > requirements. if there is PII or payment instrument information in the > "audit record" produced by this proposal, then that audit record must > either be modified to eliminate or secure the PII/PI sections, defeating > the purpose of the record, or it must be treated, in its entirety, as > PII/PI. that second option is particularly onerous. Interesting! So this problem may actually exist in the US as well, albeit not as thorough as here. So an application-level approach should not only standardize the tagging of to-be-signed content, it should actually provide two seperate tags resulting in two independent signatures, one over all the data that ought to be authenticated during processing of the transaction and one signature over only the data that is to (and legally permitted to be) persisted. Since some people are so keen on having the signature be created in close vincinity of the TLS implementation: this shouldn't be such a difficult problem. In contrast to the TLS Evidence architecture, an app-level approach is just fine with the communication/signalling capabilities of the exiting software architecture. possible Frontend-signing scheme at app-level: client -> TLS -> page request -> TLS ---> server client <- TLS <- FORM with sign-request <- TLS --- server client -> TLS (client requests signature) client <- TLS (client receives signature) client -> TLS -> POST with signed reply -> TLS ----> server No backward signalling, reversing the message stream between server and server-side TLS(-accellerator) necessary (for triggering evidence start,end, retrieving result and evidence blob) -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 19:12:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5A1E-0003na-SN; Thu, 11 Jan 2007 19:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5A1C-0003nN-VE for tls@ietf.org; Thu, 11 Jan 2007 19:11:38 -0500 Received: from bay0-omc1-s32.bay0.hotmail.com ([65.54.246.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5A19-0000zl-AV for tls@ietf.org; Thu, 11 Jan 2007 19:11:38 -0500 Received: from hotmail.com ([65.55.131.25]) by bay0-omc1-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 16:11:34 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 16:10:30 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV15.phx.gbl with DAV; Fri, 12 Jan 2007 00:10:27 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Stefan Santesson" , References: from "Stefan Santesson" at Jan 11, 7 06:33:08 pm<200701112043.VAA02623@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 16:10:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 12 Jan 2007 00:10:30.0478 (UTC) FILETIME=[12068EE0:01C735DE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan: http://europa.eu/rapid/pressReleasesAction.do?reference=IP/03/151&format=HTML&aged=0&language=EN&guiLanguage=en ----- Original Message ----- From: "Stefan Santesson" To: Cc: Sent: Thursday, January 11, 2007 2:54 PM Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Martin, Thank you for your elaborate answer and references. It would not surprise me though if Germany in this area is more radical than other EU countries, but that does not make your argument invalid. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 19:31:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AK5-0006YS-07; Thu, 11 Jan 2007 19:31:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AK3-0006Xh-Nd for tls@ietf.org; Thu, 11 Jan 2007 19:31:07 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5AK2-0007Mu-Ho for tls@ietf.org; Thu, 11 Jan 2007 19:31:07 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 46AA5A819B for ; Thu, 11 Jan 2007 19:31:24 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 0F32AA8191 for ; Thu, 11 Jan 2007 19:31:23 -0500 (EST) Message-ID: <45A6D700.4010203@pobox.com> Date: Thu, 11 Jan 2007 16:32:00 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< References: from "Stefan Santesson" at Jan 11, 7 06:33:08 pm<200701112043.VAA02623@uw1048.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I've been trying to follow this discussion, since I may have to implement this feature someday, yet I don't have a clue what it would be used for. Can someone please lay out a scenario where "evidence" collection at the TLS layer is the appropriate solution to a real problem? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 11 21:11:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Bs3-00051y-Uf; Thu, 11 Jan 2007 21:10:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Bs3-0004xZ-2V for tls@ietf.org; Thu, 11 Jan 2007 21:10:19 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5Bs0-0004yf-MB for tls@ietf.org; Thu, 11 Jan 2007 21:10:18 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id B03598297; Thu, 11 Jan 2007 20:10:13 -0600 (CST) From: "Mark Brown" To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Thu, 11 Jan 2007 20:11:49 -0600 Message-ID: <001f01c735ef$050889d0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc12y6kY5a1G32JT5iPiOKgxbUVNgAEKGtQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200701112347.AAA05530@uw1048.wdf.sap.corp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Precautions as described in TLS Evidence 6.2 use security measures that prevent accidental loss, alteration, and unauthorized disclosure or access. They are strong enough to satisfy Visa's CISP. There should be no problem. If the business determines that it has a business reason to store the TLS Evidence -- you would need that to justify buying the disk drives -- then that business reason is the business's justifying need under the directive you cite. http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html SECTION VIII - CONFIDENTIALITY AND SECURITY OF PROCESSING Article 17 Security of processing "1. Member States shall provide that the controller must implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing. "Having regard to the state of the art and the cost of their implementation, such measures shall ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected. This directive makes it clear that it will hold organizations to the highest standard of security measures in this case: "in particular where the processing involves the transmission of data over a network." But obviously TLS session encryption satisfies this standard. And obviously, persisting the packets does not degrade the encryption. So by persisting the packets, you've satisfied the highest standard. Regarding card processing: > > i know approximately nothing of EU data protection requirements, but > > something about US and payment card industry data protection > > requirements. if there is PII or payment instrument information in the > > "audit record" produced by this proposal, then that audit record must > > either be modified to eliminate or secure the PII/PI sections, defeating > > the purpose of the record, or it must be treated, in its entirety, as > > PII/PI. that second option is particularly onerous. > > Interesting! So this problem may actually exist in the US as well, > albeit not as thorough as here. In recent years Visa's CISP program became mandatory. It is available here: http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cis p_PCI_Data_Security_Standard.pdf Page 4: "Requirement 3: Protect Stored Data Encryption is the ultimate protection mechanism because even if someone breaks through all other protection mechanisms and gains access to encrypted data, they will not be able to read the data without further breaking the encryption. This is an illustration of the defense in depth principle." Visa's CISP clearly regards encryption (and good key management) highly, since here "Encryption is the ultimate protection mechanism." TLS accomplishes all this excellently. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 08:58:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mu1-0007zg-PF; Fri, 12 Jan 2007 08:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mu0-0007vz-96 for tls@ietf.org; Fri, 12 Jan 2007 08:57:04 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Mtt-0006X1-6Y for tls@ietf.org; Fri, 12 Jan 2007 08:57:04 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id OAA10366; Fri, 12 Jan 2007 14:56:39 +0100 (MEZ) From: Martin Rex Message-Id: <200701121356.OAA16779@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: mark@redphonesecurity.com (Mark Brown) Date: Fri, 12 Jan 2007 14:56:23 +0100 (MET) In-Reply-To: <001f01c735ef$050889d0$6801a8c0@rps.local> from "Mark Brown" at Jan 11, 7 08:11:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Precautions as described in TLS Evidence 6.2 use security measures that > prevent accidental loss, alteration, and unauthorized disclosure or access. > They are strong enough to satisfy Visa's CISP. There should be no problem. > > If the business determines that it has a business reason to store the TLS > Evidence -- you would need that to justify buying the disk drives -- then > that business reason is the business's justifying need under the directive > you cite. > > http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html > SECTION VIII - CONFIDENTIALITY AND SECURITY OF PROCESSING > Article 17 Security of processing I can not really comment on the US aspect of this, but for the European, and in particular for the German aspect, you are plain wrong. Since you reference the EU data protection directive, you seem to have entirely missed the much more important obligations from Article 6 (b,c,d,e). It is not up to the business to determine necessary data, and if they process it (persisting counts as processing according to Art 2 b), **they** have, among other things, to ensure accuracy of personal data, and fix or delete when they learn about inaccuracy. Although there is an clear and obvious business need for an ISP to memorize the IP address to customer mapping for a flatrate DSL customer who is online, the german court clearly declined that need after the customer hangs up. The courte issued an order to delete the record after hangup, and they also prohibited the ISP from further collecting (let alone storing) volume transfer data for the flatrate customer. The court set out a fine of 100000 Euro or 6 month in Jail for the CEO of the ISP for further non-compliance. This was about the data of ONE SINGLE CUSTOMER! That ruling was upheld by the german supreme court. As far as the blind raw communication capture approach by TLS Evidence approach is concernd -- just "accidentally" include (entirely) unnecessary and possible even incorrect data in the datastream and wait until the business has persisted the TLS Evidence. Then you can force the business to either delete the unnecessary data or to fix or delete the incorrect data in the persisted record. The EU data protection directive doesn't care whether fixing or deleting parts of the record invalidate a digital signature. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 09:14:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NAl-00008l-2R; Fri, 12 Jan 2007 09:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NAj-00008U-Ig for tls@ietf.org; Fri, 12 Jan 2007 09:14:21 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NAi-0002m4-6f for tls@ietf.org; Fri, 12 Jan 2007 09:14:21 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id PAA10426; Fri, 12 Jan 2007 15:13:40 +0100 (MEZ) From: Martin Rex Message-Id: <200701121413.PAA16990@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: ben@layer8.net (Benjamin Black) Date: Fri, 12 Jan 2007 15:13:27 +0100 (MET) In-Reply-To: <45A6FC7F.90108@layer8.net> from "Benjamin Black" at Jan 11, 7 07:11:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Benjamin Black wrote: > > section 6.2 doesn't nearly address the problem in the abstract, much > less give enough information to determine whether a specific > implementation would or would not be deemed compliant with PCIDSS. as > just one specific example, 6.2 gives no guidance whatsoever on access > control and auditing, both of which would prove especially challenging > (do you monitor access to byte ranges? do you index the streams before > encryption so that semantically meaningful byte ranges are properly > monitored? how do you even enforce access policies when someone can > access one byte range but not another when the whole stream is > encrypted? the complexity seems to be going up rapidly...). This is what I meant with "distributing an egg on every access". If TLS Evidence is used as described in a multi-level security environment, the "wire-tap" data will likely have to carry the highest security label that is permitted to travel the TLS-Endpoint, because of the braindead raw capture approach that is entirely blind to the meta-data of the communication contents. It could re-use the labelling from the peers certificate (policies), but it might still inflate the amount of data with high security labelling. The only positive side-effect might be some extra jobs for IT tech guys with high security clearance that are unlikely to be outsourced/off-shored. :-D -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 10:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OGv-00027L-DS; Fri, 12 Jan 2007 10:24:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OGt-00023u-NW for tls@ietf.org; Fri, 12 Jan 2007 10:24:47 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5OGp-0004ZO-7m for tls@ietf.org; Fri, 12 Jan 2007 10:24:47 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA00501; Fri, 12 Jan 2007 16:24:24 +0100 (MEZ) From: Martin Rex Message-Id: <200701121524.QAA17965@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: ben@layer8.net (Benjamin Black) Date: Fri, 12 Jan 2007 16:24:23 +0100 (MET) In-Reply-To: <45A6FD47.6040207@layer8.net> from "Benjamin Black" at Jan 11, 7 07:15:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Benjamin Black wrote: > > Martin Rex wrote: > > So an application-level approach should not only standardize the > > tagging of to-be-signed content, it should actually provide two > > seperate tags resulting in two independent signatures, one > > over all the data that ought to be authenticated during > > processing of the transaction and one signature over only > > the data that is to (and legally permitted to be) persisted. > > sounds like a job for ws-*, not tls. XML/XMLsig is probably OK. WS-Security (SOAP,SAML) - better not. There appears to be a serious misconception about what value "assurance" and "assurance levels" could provide to the business world. In many areas it is not only painful and entirely useless, it is even counter-productive in providing a false sense of security. High assurance in software, hardware, policies and policy processing is not going to improve accuracy and/or truth of the communicated or stored information or communication. And digital signatures blindly applied to arbitarary collections of data are a real problem for fixing or deleting inaccurate or untrue information. Appropriately engineered cryptographic integrity protection for data (in transit AND at rest) to provide resistance to tampering is perfectly sufficient. Businesses are collecting and producing data in the multi-megabyte per day range. 9 years ago, the largest database among our customers was 700 Gigabytes. I don't know what is common today, but I assume that several have long crossed the Terabyte mark. So it is a sad fact that a lot of inaccurate information is processed and stored by businesses every day, and applying digital signatures on raw communication data will hardly have any benefits for the businesses, but TLS Evidence will come at a cost and create a significant performance impact (latency). I mentioned it before, for Online shopping it will be pretty useless. See http://www.heise.de/newsticker/meldung/83574 (sorry, it's all German). Amazon had put up Sony&IBM laptops at less than EUR 20 in their online shop and of course, several customers ordererd them. This is why businesses make sure that such offers are not binding, because error like these happen every once in a while. This illustrate just what a stupid idea TLS Evidence would be in these scenarios. Maybe the President could claim that he received [EAL6] assured evidence from intelligence that Saddam was working on nuclear WMD without actually lying. He probably is using highly assured equipment and is communicating over highly assured communication links only. Highly assured equipment higly assures that garbage in will result in highly assured and expensive garbage out. I also think that trying to provide any level of "non-repudiation" on content (especially raw content) is just the opposite of where everyone should be going. Many US supermarkets have had a customer friendly return policy for many years. In Germany we didn't have it for quite a long time, it came up a few years ago. For online&telephone shopping, a very customer-friendly return policy was enacted as law just 3/4 years ago. Today, we usually do not have disputes about the content of an order that was placed, but rather about characteristics or quality of the product, inaccuracies of the advertisement and intend of the customer placing the order. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 13:37:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RG4-0008Ss-BB; Fri, 12 Jan 2007 13:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RG2-0008Si-Q2 for tls@ietf.org; Fri, 12 Jan 2007 13:36:06 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RFz-0006PR-6T for tls@ietf.org; Fri, 12 Jan 2007 13:36:06 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id D435B81EC; Fri, 12 Jan 2007 12:35:57 -0600 (CST) From: "Mark Brown" To: "'EKR'" , , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration Date: Fri, 12 Jan 2007 12:37:34 -0600 Message-ID: <003a01c73678$b9ee0df0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccxPOHV4Op3Ok4nSP6jcpxh0qIapwEi+4Gw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <86mz4wan3q.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin, Eric, Below is an illustration of how to use TLS Evidence for a brokerage transaction. I hope with this illustration I can address both of your concerns about what data needs to be signed and retained, and using what amount of automation. In this example I am not using the start1, start2, etc. alerts, since I suggested this earlier as a possible simplification of the current draft. Eric Rescorla said: > >> I think "not great" is quite an understatement here. You've just > >> required that every TLS record write requires *two* signatures, > >> one from the sender and one from the receiver. This includes > >> record read/writes which the application doesn't even care > >> about having evidence for. Your typical brokerage transaction > >> requires 10s if not hundreds of separate HTTP fetches, each > >> of which requires one or more record in each direction. Doing > >> 25 digital signatures for every transaction is an enormous > >> load on the server. I suggested: > > Turn on TLS Evidence only for one POST, skip the GETs. There's > typically > > one important POST per transaction, the one before the > > print-this-page-for-your-records response. That's the page the user > > typically prints for evidence of the transaction, despite its failings. > > Yes, but *now* you're in the business of having the application > require tight control of when signatures are created and when > they're available, which brings us back to the situation I > was complaining about in my initial review, where this isn't > just automatic, it requires esxtensively modifying the > app, plus the race condition/lockstep issues I raised in my > original review. So, Eric is concerned about situations where the creation of the signature "isn't just automatic, it requires esxtensively modifying the app..." and Martin is concerned about the situations where embedded within an (automatically-created?) signature there exists "personal data" that is captured without consent or is not necessary to the business purpose of the transaction (and needs to be expunged later). Can an application-data-blind protocol extension like TLS Evidence address both concerns? (Here I want "blind" to mean that TLS Evidence doesn't peek into the application_data.) Let me retrace Eric's line of thought first, using his broker illustration: 1) 100's of fetches to accomplish a trade: In HTTP the TCP/IP session gets torn down after every fetch. So what is going on in Eric's scenario are "hundreds" of TLS resumes, after an initial full TLS handshake. 2) I'm proposing to do a full handshake using the TLS Evidence extension only for the last POST, not the 100's of fetches prior to the POST. That is, not doing a TLS resume for the last POST but discarding the existing TLS session and forming a new one. Note that the HTTP app data is what actually creates the user's sense of a session that persists over the hundreds of fetches (and a few other POSTs). That app data doesn't care if you resume every time, do a full handshake every time, or any combination. 3) So I propose a minimum of two full-handshake TLS sessions, one that uses TLS Evidence and one that doesn't. In the brokerage scenarion, the TLS session that does not employ TLS Evidence will be used for much more data than the TLS Evidence session. TLS Evidence will only be captured for a typical brokerage transaction containing the client's POSTDATA and the server's HTTP Response. (This HTTP Response will only contain browser-readable HTML and cookies and not contain GIFs, JPEGs, CSS, Javascript, ActiveX, etc., although it could contain references to any of these. All such references will need to be fetched by the client's user agent, likely using TLS resumes on a TLS session that was used for the 100s or previous fetches.) I believe this is normal user agent operation today, provided the normal TLS session connects to a different domain name than the TLS Evidence session. So in this illustration, I'll use a different DN for the "evidence" TLS server than for the "secure" TLS server. Using a different DN for a TLS Evidence TLS instance than the DN used by the "normal" TLS instance is not the only way to accomplish the required distinction between plain TLS and TLS Evidence sessions, but I think it is the most backwards compatible approach. Here's a proposed illustration for a simple use of TLS Evidence, for the case of "Your typical brokerage transaction". A) Client may start at http://www.broker.com, without TLS. B) Client logs into https://secure.broker.com, using some URL path (PKC 1 is for secure.broker.com) and fires up a normal TLS session to host "secure.broker.com". In this illustration, authentication at this host is done using user name and password at the application level, not at TLS level. C) Client interacts -- 100s of fetches, etc. -- using the normal TLS session D) Web App designer has already changed the URL on the FORM SUBMIT action of the one important POST so that it targets https://evidence.broker.com instead of the "secure" server. This obviously forces a full handshake regardless of the TLS Evidence extension -- the old TLS session won't work here because of the DN change. Server must use PKC 2 for evidence.broker.com. E) client MUST have already been configured at TLS level in this way: (Target) evidence.broker.com:443 = (PKC) clientEvidence3 This TLS client configuration line identifies one DNS name and port number for which the client will always ClientHello using TLS Evidence. Further, for sessions with this DNS host the specified client PKC will be used for signing the TLS Evidence. To one of Martin's concerns, the TLS client is free to add or remove Target=PKC TLS Evidence configuration lines at any time, or simply let his PKC expire, or review servers for which he has configured Evidence, etc. Client configuration could also record (in a third column) a URL at which the client could request destruction of TLS Evidence. Stronger implementations could use a full URL/URI as the (Target). I propose only DN here because the current client API suggested by the OpenSSL s_client command line interface is just a hostname, or hostname plus port. This configuration is on par with the configuration of trusted CA's, the specification of the client's private key file and password, etc. in the OpenSSL s_client. So at this level of the existing API, the configurations given to s_client are "trusted". So the level of consent in the proposed configuration is equivalent to the level of consent for which CA's to trust. F) After connection, a TLS session using TLS Evidence exists. Over the course of time, between this client and the server with domain name evidence.broker.com, you might see: ClientHello1 (full handshake, TLS Evidence) C: + Rq1.1 | | Rs1.2 S: | Rs1.1 + + Rq1.2 | WHERE: C = client S = server The following are numbered by ClientHello then app_data sequence: = application data Rq#.# = EvidenceRequest Rs#.# = EvidenceResponse So, this evidence session created Rs1.1 and Rs1.2 as evidence, and Rs1.2 has the hash of in the app_data_received_hash (because TLS server initiated this EvidenceRequest) and the hash of in the app_data_sent_hash, and the hash of "ClientHello1 (full handshake, TLS Evidence)" with evidence.broker.com in the handshake_protocol_hash. Rs1.1 is pretty much obsolete now that Rs1.2 exists. What if the app designers couldn't identify just one HTTP POST to capture TLS Evidence for? What if 100s more fetches were performed and the user initiated a second brokerage transaction? Then the following uses of the evidence session might occur: ClientHello2 (resume, TLS Evidence) C: + Rq2.1 | | Rs2.2 S: | Rs2.1 + + Rq2.2 | ClientHello3 (resume, TLS Evidence) C: + Rq3.1 | | Rs3.2 S: | Rs3.1 + + Rq3.2 | To one of Eric's concerns, in this illustration there really is no change required for either the TLS client or the TLS server APIs (i.e. how the application interacts programmatically with the TLS layer). In this illustration the client is configured via command line as described above. Server may implement TLS Evidence using a command-line, config-file or compiled-in option. Whenever client interacts with https://evidence.broker.com, TLS Evidence will be requested and created, and if there's any problem the TLS session will get torn down, browser will say page unavailable, and the back button will be used. Resumes will still work on the "normal" TLS session, which will be used independently of the "evidence" session. >From the perspective of the application deployment at the web server, they may choose to host two web sites on the same machine (or not). They may develop the "evidence" page, i.e. the web application that accepts the POSTDATA, using "normal" TLS. They may choose to copy that web application (CGI, JSP, ASP, servlet, etc.) from the "normal" TLS site to the "evidence" TLS site. They may even choose to allow users to select whether the user would prefer to send their POSTDATA to the "evidence" or the "normal" site. This would probably be a good idea in case any of their clients will ever have difficulty with their PKCs. To one of Martin's concerns, what data is actually preserved in this example? The TLS handshake, the POSTDATA sent by the TLS client, and the HTTP Response "web page" (before any referenced documents like images, CSS, scripts, etc. are fetched). These three cases may only run afoul of laws governing the retention of personal data in the data preserved in the following streams: 1) the POSTDATA (i.e. form fields "filled in" by the user within the user agent using the TLS session) may contain extraneous data fields that are really not 2) the HTTP Response data (i.e. the "web page" returned by the server) 3) The TLS Handshake data for this particular TLS Evidence Session In the first case, the POSTDATA is fully determined by the server side, which created the HTTP page and HTTP form which is being posted. Of course, the only data being posted are HTML HIDDEN fields, any relevant cookies (by domain name, etc.), the fields within the HTML FORM tag which have been further tagged as FORM fields and further, have been filled in by the user. In this illustration, the broker created the blank FORM which the user fills in. This is simply a more widely used method of identifying the fields to be used for evidence than the new tags Martin mentioned earlier as a preferred solution: Martin Rex said: > Instead of having to redesign and rewrite the entire application protocol > stack for every use case in order to accomodate what data will and > will not become part of the TLS Evidence, one can make it a configuration > option for the customer in the application. So all of the attributes > that the backend wants to get signed will be tagged as such in > the request from the backend to the frontend. Auxiliary information > will go untagged and not be included in the signature. Because > the app knows what it wants signed, it can actually verify that it > receives what it is looking for. >From the customer's standpoint, the HTML FORM approach is nearly WYSIWYG, except for the cookies and hidden fields. From a legal standpoint, the form designer at the brokerage will need to ensure that none of these fields violate applicable laws when persisted. In the second case all of the HTML and cookies returned to the user are 100% under the brokerage's control, as in the first case. If the brokerage is in the habit of returning transaction receipts to their users that are illegal for some entities to persist then it makes more sense to change the HTML & cookies returned than to continue to risk breaking the law. This is a matter of correctly implementing the business requirements into the application, and really isn't the concern of the TLS layer. It is, arguably, fairly easy for the broker to change the dubiously-legal HTML application, and it is clearly the broker's responsibility. In the third case, a normal SSL/TLS handshake already has the capability to authenticate a PKC, and it already performs HMAC over the application data. I would be surprised if any nation has passed or will pass laws that made TLS records illegal to store / audit. However, even where such laws are in force, TLS Evidence can still be used simply by truncating any of the application data records and/or TLS handshake records as described below. Finally, all three of these audit streams -- app data sent, app data received and TLS handshake -- are severable. If the app data sent by the client needed to be destroyed upon request by the user, then it could be destroyed without ruining the digital signature set. Same for the other streams. In fact, if an entity only persisted the TLS Evidence EvidenceResponse structure and none of the streams, it would still hold a fairly strong method of falsifying any fraudulent claims. For if a frivolous opponent chose to claim that a specific set of app data sent, app data received and TLS handshake took place, the brokerage could simply challenge that assertion and say, "Prove it: we've retained evidence over every transaction we've authorized; let's see if your claim matches any transmissions we've processed for your PKC." This approach may even reduce the overall burden of data retention on the brokerage, since the EvidenceResponse structures are relatively small. In summary, TLS Evidence can be used to falsify frivolous / fraudulent claims without storing any application data or handshake streams. TLS Evidence can be "turned on" and "turned off" by using a DNS domain name, and this approach follows not only the traditional SSL/TLS API but also the Berkeley sockets API, so it is legacy compatible. TLS Evidence, used as described, requires the TLS Client to maintain a trusted configuration store that matches client certificates to the domain names at which those certificates should be used, and this whitelist follows the same conventions as the existing trusted CA configuration process. Martin points out a good legal motivation for only generating TLS Evidence when you REALLY need it, and storage considerations also encourage this approach; I strongly agree that TLS Evidence should be "turned on" only when a core-to-the-business transaction needs to be recorded. I expect these three motivations -- which I summarize as relevant legal constraints, business needs and security goals -- will work together to help TLS Evidence users make the right decisions. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 13:54:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RXC-0003v9-9o; Fri, 12 Jan 2007 13:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RXA-0003v0-OL for tls@ietf.org; Fri, 12 Jan 2007 13:53:48 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RX5-0003ZL-1c for tls@ietf.org; Fri, 12 Jan 2007 13:53:48 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 55B201E8C28; Fri, 12 Jan 2007 10:53:42 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration References: <003a01c73678$b9ee0df0$6801a8c0@rps.local> From: Eric Rescorla Date: Fri, 12 Jan 2007 10:53:42 -0800 In-Reply-To: <003a01c73678$b9ee0df0$6801a8c0@rps.local> (Mark Brown's message of "Fri, 12 Jan 2007 12:37:34 -0600") Message-ID: <86k5zsjcuh.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: > Let me retrace Eric's line of thought first, using his broker illustration: > > 1) 100's of fetches to accomplish a trade: In HTTP the TCP/IP session gets > torn down after every fetch. Uh, not in any modern HTTP stack, no. I refer you to RFC 2616 S 8.1. > This TLS client configuration line identifies one DNS name and port number > for which the client will always ClientHello using TLS Evidence. It does what??? I need to hard-configure some list of names and ports? That scales how? > To one of Eric's concerns, in this illustration there really is no change > required for either the TLS client or the TLS server APIs (i.e. how the > application interacts programmatically with the TLS layer). No. The server *still* needs to check that he's actually getting evidence. I.e., that the client is coming in through the right virtual server (unless you're proposing that I rearchitect all my server apps to split every kind of transaction into two different servers), and there's still the relative inefficiency of your signature mechanism, which is conservatively a factor of 2-4 slower than app-level signatures. So, you've had to modify both client and server, you quite possibly had to substantially rearchitect the server, and the client has to have some semi-manual configuration settings to determine when it offers evidence. None of this seems particularly convenient. To uplevel a moment, I'm not arguing that you can't make some proposal along the lines you indicate sort of work. What I am arguing is that it isn't substantially simpler than the application-level signature alternatives, that it offers inferior semantics, and that it doesn't fit well with the TLS architecture. None of this discussion has changed my views on that point. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 14:25:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S0z-0000i8-7O; Fri, 12 Jan 2007 14:24:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S0y-0000hl-01 for tls@ietf.org; Fri, 12 Jan 2007 14:24:36 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5S0u-00030F-Ka for tls@ietf.org; Fri, 12 Jan 2007 14:24:35 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 12 Jan 2007 19:24:30 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 12 Jan 2007 19:24:29 +0000 From: Stefan Santesson To: "home_pw@msn.com" , "martin.rex@sap.com" Date: Fri, 12 Jan 2007 19:24:27 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: Acc13hWpameOCbufSxmAFu6fE3aPhgAoB1Qw Message-ID: References: from "Stefan Santesson" at Jan 11, 7 06:33:08 pm<200701112043.VAA02623@uw1048.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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I think we can clearly separate the issue of information sharing from an ID= authentication technology from this draft dealing with capturing and signi= ng information shared between two parties. The relevant issue your raise is if the capturing of data from lower commun= ication layers and storing them as part of a signed audit record can be pro= blematic from a user integrity perspective. I think you have made strong ar= guments that it can. I'm still trying to figure out exactly how big of a problem this is but thi= s might very well be the reason why this proposal is a bad idea. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: home_pw@msn.com [mailto:home_pw@msn.com] > Sent: den 11 januari 2007 16:10 > To: Stefan Santesson; martin.rex@sap.com > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > Stefan: > > http://europa.eu/rapid/pressReleasesAction.do?reference=3DIP/03/151&forma > t=3DHTML&aged=3D0&language=3DEN&guiLanguage=3Den > > > ----- Original Message ----- > From: "Stefan Santesson" > To: > Cc: > Sent: Thursday, January 11, 2007 2:54 PM > Subject: RE: [TLS] Please discuss: > draft-housley-evidence-extns-00< > > Martin, > > Thank you for your elaborate answer and references. > It would not surprise me though if Germany in this area is > more radical than other EU countries, but that does not make > your argument invalid. > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 14:55:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SUi-0003wc-F5; Fri, 12 Jan 2007 14:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SUg-0003wX-TR for tls@ietf.org; Fri, 12 Jan 2007 14:55:18 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5SUe-0001C0-T9 for tls@ietf.org; Fri, 12 Jan 2007 14:55:18 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 297F881E4; Fri, 12 Jan 2007 13:55:14 -0600 (CST) From: "Mark Brown" To: "'EKR'" Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration Date: Fri, 12 Jan 2007 13:56:50 -0600 Message-ID: <003e01c73683$cce51790$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc2ewvJE07cKF2TTjac1MNV2In4hgAAVMVw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <86k5zsjcuh.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, > > 1) 100's of fetches to accomplish a trade: In HTTP the TCP/IP session gets > > torn down after every fetch. > > Uh, not in any modern HTTP stack, no. I refer you to RFC 2616 S 8.1. You're right. > > This TLS client configuration line identifies one DNS name and port > number > > for which the client will always ClientHello using TLS Evidence. > > It does what??? I need to hard-configure some list of names and ports? > That scales how? You're right again. I could drop the port number; then it scales about as well as using client certs. I think the "scales well?" comparison here should be made against client cert use cases. > > To one of Eric's concerns, in this illustration there really is no > change > > required for either the TLS client or the TLS server APIs (i.e. how the > > application interacts programmatically with the TLS layer). > > No. The server *still* needs to check that he's actually getting > evidence. I.e., that the client is coming in through the right > virtual server This seems like a misunderstanding. I'm proposing two web servers over two TLS instances using two PKCs in this illustration. On the web server using the "evidence" TLS instance you don't need to check for EvidenceResponse any more than the web server on a normal TLS instance double checks that encryption was performed. TLS Evidence is on or it's not. Is your concern the semantics? In the brokerage scenario, the second EvidenceResponse either is or it isn't. What does the brokerage care if the TLS client never countersigns the issued receipt? The TLS layer's TLS Evidence implementation will ensure that no further application data is allowed back up to the app server in this case. If the TLS client drops off and hangs up, there's no problem. If the TLS client skips its countersignature and yet still wants to turn around and send more app data then the TLS Evidence implementation will block this. > there's still the relative inefficiency > of your signature mechanism, which is conservatively a factor of 2-4 > slower than app-level signatures. Yes, you're right. Twice-signed is slower than single-signed, especially when you figure in network latency as proposed. Using order-of-magnitude computations, twice-signed is probably about as costly as a TLS handshake. Both estimates really hinge on network latency which is a bit of a wildcard. > So, you've had to modify both client and server, you quite > possibly had to substantially rearchitect the server, and the > client has to have some semi-manual configuration settings to > determine when it offers evidence. None of this seems > particularly convenient. I expect that most TLS Extensions will require some modification to the TLS instance, modifying both client and server. My goal is to eliminate impact on the TLS-app API except for opt-ins to TLS Evidence, and then, to minimize impact. I've made progress, thanks to input on this list. I think we're currently at "no impact" unless opt-in occurs. Where opt-in occurs, I believe that the server impact occurs only at TLS server installation / configure time. Client has to configure per-cert as its opt-in action, assuming a TLS Evidence instance already exists. I think that overall this is shaping up to be pretty close to current TLS practice, but I'm interested in your opinion. > To uplevel a moment, I'm not arguing that you can't make some proposal > along the lines you indicate sort of work. What I am arguing is that > it isn't substantially simpler than the application-level signature > alternatives, that it offers inferior semantics, and that it doesn't > fit well with the TLS architecture. None of this discussion has > changed my views on that point. > > -Ekr I think that if we can work out the sorts of concerns you raise here, we will save applications from having to make these exact mistakes (and worse) over and over again. Your suggestions and others are valuable and based on a lot of experience that most of the rest of us don't have. Let's move this entire discussion forward for everyone by making the compromises that stick and documenting them in a spec. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 15:26:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SyZ-0006UT-12; Fri, 12 Jan 2007 15:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SyX-0006RV-Io for tls@ietf.org; Fri, 12 Jan 2007 15:26:09 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5SyV-0000ed-61 for tls@ietf.org; Fri, 12 Jan 2007 15:26:09 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA01737; Fri, 12 Jan 2007 21:25:58 +0100 (MEZ) From: Martin Rex Message-Id: <200701122025.VAA23310@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration To: mark@redphonesecurity.com (Mark Brown) Date: Fri, 12 Jan 2007 21:25:57 +0100 (MET) In-Reply-To: <003a01c73678$b9ee0df0$6801a8c0@rps.local> from "Mark Brown" at Jan 12, 7 12:37:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark, Mark Brown wrote: > > Below is an illustration of how to use TLS Evidence for a brokerage > transaction. I appreciate your efforts, but I'm running out of time with this debate. I'm behind on my development schedule and need to go back do the work I'm being paid for. There will always be means to use a inappropriate technology for an inadequate solution, I can see it every day when deployed technology is frobbed^Wretrofitted for a purpose for which it wasn't designed. However, it is a pretty bad idea to start off with a technology that fits common scenarios in home/office/businesses so poorly as TLS Evidence and has such a huge abusive potential. I know that there is a huge economic motivation for government agencies to be able to purchase equiment on the free market that suits their needs rather than having to develop it on their own. This is one of the reasons how/why TPM sneaked into modern business computers for the mass market. There is some truth in what Peter says, the proposal is so well designed, and many of the things people recognize as problems are there on a purpose and integral part of the proposal, so the most severe problems are beyond repair. IMHO, if TLS Evidence is rubberstamped, it means that the IETF has been subverted sucessfully. If this technology enters the maintstream, then the agencies will start harvesting the results. They've been pretty firm in how much they like and intend to expand surveillance, and they are regularly breaking the laws in order to collect information to which they're not entitled. The most effective security measure is not protecting data with strong crypto and high assurance, it is not creating -- or where it needs to be created and processed -- not persisting it. As far as risk management is concerned, TLS Evidence is probably the largest can of worms I've ever seen. Since I've started thinking about this technology, I discover at least one major new problem every day (acutally every night when I try to get asleep), and I have the feeling that I've only seen the tip of the iceberg so far. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 15:39:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TAe-0004Yc-BF; Fri, 12 Jan 2007 15:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TAc-0004Wu-Ua for tls@ietf.org; Fri, 12 Jan 2007 15:38:38 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5TAb-0002ns-DA for tls@ietf.org; Fri, 12 Jan 2007 15:38:38 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 755011E8C28; Fri, 12 Jan 2007 12:38:36 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration References: <003e01c73683$cce51790$6801a8c0@rps.local> From: Eric Rescorla Date: Fri, 12 Jan 2007 12:38:36 -0800 In-Reply-To: <003e01c73683$cce51790$6801a8c0@rps.local> (Mark Brown's message of "Fri, 12 Jan 2007 13:56:50 -0600") Message-ID: <861wm0htf7.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: >> > This TLS client configuration line identifies one DNS name and port >> number >> > for which the client will always ClientHello using TLS Evidence. >> >> It does what??? I need to hard-configure some list of names and ports? >> That scales how? > > You're right again. I could drop the port number; then it scales about as > well as using client certs. Preconfiguring all the servers you're willing to sign with scales as well as installing a single client cert? >> > To one of Eric's concerns, in this illustration there really is no >> change >> > required for either the TLS client or the TLS server APIs (i.e. how the >> > application interacts programmatically with the TLS layer). >> >> No. The server *still* needs to check that he's actually getting >> evidence. I.e., that the client is coming in through the right >> virtual server > > > This seems like a misunderstanding. I'm proposing two web servers over two > TLS instances using two PKCs in this illustration. On the web server using > the "evidence" TLS instance you don't need to check for EvidenceResponse any > more than the web server on a normal TLS instance double checks that > encryption was performed. TLS Evidence is on or it's not. But they're not two TLS servers now, they're one. So, you're proposing a massive rearchitecture of people's servers--and think about this scales next time you want to add such a feature! Easier to just add message signing, which doesn't require any such rearchitecture. >> there's still the relative inefficiency >> of your signature mechanism, which is conservatively a factor of 2-4 >> slower than app-level signatures. > > Yes, you're right. Twice-signed is slower than single-signed, especially > when you figure in network latency as proposed. Using order-of-magnitude > computations, twice-signed is probably about as costly as a TLS handshake. You're assuming that each transaction is only covered by one set of signatures. But there's no such requirement in TLS. You can send every byte as a separate SSL record--and it's quite common for an HTTPS response to span multiple records. >> So, you've had to modify both client and server, you quite >> possibly had to substantially rearchitect the server, and the >> client has to have some semi-manual configuration settings to >> determine when it offers evidence. None of this seems >> particularly convenient. > > I expect that most TLS Extensions will require some modification to the TLS > instance, modifying both client and server. My goal is to eliminate impact > on the TLS-app API except for opt-ins to TLS Evidence, and then, to minimize > impact. I've made progress, thanks to input on this list. I think we're > currently at "no impact" unless opt-in occurs. Where opt-in occurs, I > believe that the server impact occurs only at TLS server installation / > configure time. Client has to configure per-cert as its opt-in action, > assuming a TLS Evidence instance already exists. I think that overall this > is shaping up to be pretty close to current TLS practice, but I'm interested > in your opinion. I don't agree with this assessment, for reasons I think I've indicated as nauseum. >> To uplevel a moment, I'm not arguing that you can't make some proposal >> along the lines you indicate sort of work. What I am arguing is that >> it isn't substantially simpler than the application-level signature >> alternatives, that it offers inferior semantics, and that it doesn't >> fit well with the TLS architecture. None of this discussion has >> changed my views on that point. >> >> -Ekr > > I think that if we can work out the sorts of concerns you raise here, we > will save applications from having to make these exact mistakes (and worse) > over and over again. But to a first order, these mistakes are a result of your attempt to put signatures at a layer with inappropriate semantics. There are a lot fewer mistakes to be made if the signatures are done at the right layer. And I'm not at all convinced that any amount of hacking on this general architecture will produce an acceptable result. > Your suggestions and others are valuable and based on > a lot of experience that most of the rest of us don't have. Let's move this > entire discussion forward for everyone by making the compromises that stick > and documenting them in a spec. You're assuming the exact point I'm contesting, which is that this should be done at all. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 18:44:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5W35-0005aZ-UP; Fri, 12 Jan 2007 18:43:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5W35-0005aU-1t for tls@ietf.org; Fri, 12 Jan 2007 18:43:03 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5W32-00032f-ML for tls@ietf.org; Fri, 12 Jan 2007 18:43:03 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id AAA25967; Sat, 13 Jan 2007 00:42:52 +0100 (MEZ) From: Martin Rex Message-Id: <200701122342.AAA27604@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration To: mark@redphonesecurity.com (Mark Brown) Date: Sat, 13 Jan 2007 00:42:51 +0100 (MET) In-Reply-To: <003a01c73678$b9ee0df0$6801a8c0@rps.local> from "Mark Brown" at Jan 12, 7 12:37:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mark Brown wrote: > > Below is an illustration of how to use TLS Evidence for a brokerage > transaction. Since you keep refering to brokerage transactions, audit trail, Microsoft is participating the discussion, and TLS Evidence is being designed to be able to work "transparently" (=concealed), I'm wondering whether this is primarily targetted for the financial sector and stock exchanges. That's already a fairly regulated area, and an area where massive legal and illegal wire-tapping is ongoing (e.g. SWIFT). The agencies might be looking for a means to capture the evidence even for a larger amount of deployed software, so a transparent (or actually concealed) plug-in to the TLS stack might be attractive to them. Performance is likely an issue there as well, so the approach of hosting the transaction "forms" (actually the reveiving URLs for the HTTP Post on a dedicated Web-Server might be the easiest way to cut down the audit trail considerably, improve the performance and reduce the necessary changes in the backend significantly... It appears that for the audit trail on the backend a windows box with a tls-terminating loadbalancer or reverse-proxy is envisioned, and the frontends are probably all windows PCs these days. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 12 20:47:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5XzE-0004S2-9L; Fri, 12 Jan 2007 20:47:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5XzC-0004Rx-Js for tls@ietf.org; Fri, 12 Jan 2007 20:47:10 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5XzB-0005Bd-7P for tls@ietf.org; Fri, 12 Jan 2007 20:47:10 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA12934; Sat, 13 Jan 2007 02:46:49 +0100 (MEZ) From: Martin Rex Message-Id: <200701130146.CAA29905@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage To: ben@layer8.net (Benjamin Black) Date: Sat, 13 Jan 2007 02:46:49 +0100 (MET) In-Reply-To: <45A81E44.6040501@layer8.net> from "Benjamin Black" at Jan 12, 7 03:48:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Benjamin Black wrote: > > i think it would be a mistake to construe participation in this > discussion by someone from microsoft as any form of endorsement by > microsoft of this proposal or any similar proposal that might emerge. I'm sorry. When I read in the new that the NSA officially acknowlegde having worked with Microsoft on Vista, I was wondering whether they were working on multi-level security support (not the abusive aspects). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 13 14:55:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5oxv-0000UV-I2; Sat, 13 Jan 2007 14:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5oxu-0000UO-Lk for tls@ietf.org; Sat, 13 Jan 2007 14:54:58 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5oxs-0005i7-A6 for tls@ietf.org; Sat, 13 Jan 2007 14:54:58 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0DJst3O016513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 13 Jan 2007 11:54:55 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0DJssDZ021105 for ; Sat, 13 Jan 2007 11:54:55 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jan 2007 11:54:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jan 2007 11:54:54 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Stateless TLS Session Resumption Thread-Index: Acc3TLHsrx0WXtswTt28sO/OoPUYjQ== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 13 Jan 2007 19:54:54.0881 (UTC) FILETIME=[B21FA910:01C7374C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [TLS] Question on Stateless TLS Session Resumption X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org All, RFC4507 makes no mention of ticket replays at all, which I find to be a bit surprising. It actually doesn't talk about message replays either, but, since the protocol takes 1.5 RTs, both parties prove to be live and so, that is not a problem. But, ticket replays seem to be of some concern. Based on the fact that the ticket contains a timestamp, using which expiry can be determined, it appears that a given ticket will be accepted until its expiry time, even if a newer ticket may have been issued after that. This itself is not so much a problem, since, the client really has no incentive in using an older ticket as opposed to the latest one. However, if a new ticket is either not issued or if the session is terminated by the server for some reason, this seems to be a problem. Since there is really no means of ticket revocation or any server state on the status of a ticket, there seems to be no way to determine that the client is not supposed to be using that ticket to resume a session. Also, the fact that the client is allowed to pick a Session ID makes it infeasible to track a terminated session that must not be allowed to resume.=20 Am I missing something? Has this been talked about before?=20 Vidya _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 13 16:53:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5qoV-0001Dg-7q; Sat, 13 Jan 2007 16:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5qoU-0001Db-Nf for tls@ietf.org; Sat, 13 Jan 2007 16:53:22 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5qoT-0008Nc-CO for tls@ietf.org; Sat, 13 Jan 2007 16:53:22 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 70C211E8C28; Sat, 13 Jan 2007 13:53:18 -0800 (PST) To: "Narayanan, Vidya" Subject: Re: [TLS] Question on Stateless TLS Session Resumption References: From: Eric Rescorla Date: Sat, 13 Jan 2007 13:53:18 -0800 In-Reply-To: (Vidya Narayanan's message of "Sat, 13 Jan 2007 11:54:54 -0800") Message-ID: <863b6eh9v5.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org [Re-sending to the mailing list...] "Narayanan, Vidya" writes: > All, > RFC4507 makes no mention of ticket replays at all, which I find to be a > bit surprising. It actually doesn't talk about message replays either, > but, since the protocol takes 1.5 RTs, both parties prove to be live > and so, that is not a problem. But, ticket replays seem to be of some > concern. Based on the fact that the ticket contains a timestamp, using > which expiry can be determined, it appears that a given ticket will be > accepted until its expiry time, even if a newer ticket may have been > issued after that. Right. There's nothing wrong with this. > This itself is not so much a problem, since, the > client really has no incentive in using an older ticket as opposed to > the latest one. However, if a new ticket is either not issued or if the > session is terminated by the server for some reason, this seems to be a > problem. Well, there are two separate issues here. There's no technical reason why a new TLS handshake between a client/server pair needs to invalidate and old session between them. Indeed, I don't know of any server which enforces this before and it would even in principle be rather difficult to do in the absence of client authentication, which is fairly rare. This leaves us with ticket invalidation which does, as you note, require server side state, though rather less than that required by an ordinary session cache. > Since there is really no means of ticket revocation or any > server state on the status of a ticket, there seems to be no way to > determine that the client is not supposed to be using that ticket to > resume a session. Also, the fact that the client is allowed to pick a > Session ID makes it infeasible to track a terminated session that must > not be allowed to resume. I don't think I understand this point. Both session IDs and tickets are generated by servers. > Am I missing something? Has this been talked about before? Yes, it's discussed extensively in the SBR04 paper on Client-Side Session Caching. Shacham, H., Boneh, D., and E. Rescorla, "Client-side caching for TLS", Transactions on Information and System Security (TISSEC) , Volume 7, Issue 4, November 2004. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 13 19:07:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5st2-0000g7-29; Sat, 13 Jan 2007 19:06:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5st0-0000fh-4j for tls@ietf.org; Sat, 13 Jan 2007 19:06:10 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5ssx-0003VD-Nd for tls@ietf.org; Sat, 13 Jan 2007 19:06:10 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0E0653C023448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 13 Jan 2007 16:06:06 -0800 Received: from [10.50.76.70] (qconnect-10-50-76-70.qualcomm.com [10.50.76.70]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0E065OY012570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Jan 2007 16:06:05 -0800 (PST) Message-ID: <45A973A0.4000105@qualcomm.com> Date: Sat, 13 Jan 2007 16:04:48 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Question on Stateless TLS Session Resumption References: <863b6eh9v5.fsf@raman.networkresonance.com> In-Reply-To: <863b6eh9v5.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > Well, there are two separate issues here. There's no technical > reason why a new TLS handshake between a client/server pair > needs to invalidate and old session between them. Indeed, > I don't know of any server which enforces this before and it > would even in principle be rather difficult to do in the > absence of client authentication, which is fairly rare. The issue is that of revocation. If a client's credentials are revoked, a full exchange will ensure that the client gets service only after it acquires/renews its certificate or whatever. If there is an old ticket that the client can use to get service then it is able to get around having to reauthenticate with new credentials. > > This leaves us with ticket invalidation which does, as you > note, require server side state, though rather less than > that required by an ordinary session cache. > > >> Since there is really no means of ticket revocation or any >> server state on the status of a ticket, there seems to be no way to >> determine that the client is not supposed to be using that ticket to >> resume a session. Also, the fact that the client is allowed to pick a >> Session ID makes it infeasible to track a terminated session that must >> not be allowed to resume. > > I don't think I understand this point. Both session IDs and > tickets are generated by servers. Right, that's as per 4346. However, 4507 says "When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello." Given that the client can change the session id, it becomes difficult (not impossible as I initially thought) for the server to track and invalidate old tickets. But, perhaps as you say, this is generally not an issue in practice. If the ticket lifetime is generally short enough, it is probably not a big deal (although it would have been nice to have stated it in 4507). regards, Lakshminath > > >> Am I missing something? Has this been talked about before? > > Yes, it's discussed extensively in the SBR04 paper on Client-Side > Session Caching. > > Shacham, H., Boneh, D., and E. Rescorla, "Client-side > caching for TLS", Transactions on Information and System > Security (TISSEC) , Volume 7, Issue 4, November 2004. > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 13 19:29:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5tEy-00064e-KI; Sat, 13 Jan 2007 19:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5tEx-00063V-PC for tls@ietf.org; Sat, 13 Jan 2007 19:28:51 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5tEv-0008S3-CU for tls@ietf.org; Sat, 13 Jan 2007 19:28:51 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 93AC81E8C28; Sat, 13 Jan 2007 16:28:48 -0800 (PST) To: Lakshminath Dondeti Subject: Re: [TLS] Question on Stateless TLS Session Resumption References: <863b6eh9v5.fsf@raman.networkresonance.com> <45A973A0.4000105@qualcomm.com> From: Eric Rescorla Date: Sat, 13 Jan 2007 16:28:48 -0800 In-Reply-To: <45A973A0.4000105@qualcomm.com> (Lakshminath Dondeti's message of "Sat, 13 Jan 2007 16:04:48 -0800") Message-ID: <86irfafo3j.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Lakshminath Dondeti writes: > Eric Rescorla wrote: > >> Well, there are two separate issues here. There's no technical >> reason why a new TLS handshake between a client/server pair >> needs to invalidate and old session between them. Indeed, >> I don't know of any server which enforces this before and it >> would even in principle be rather difficult to do in the >> absence of client authentication, which is fairly rare. > > The issue is that of revocation. If a client's credentials are > revoked, a full exchange will ensure that the client gets service only > after it acquires/renews its certificate or whatever. If there is an > old ticket that the client can use to get service then it is able to > get around having to reauthenticate with new credentials. Yes, as I said there are *two* issues. One issue is about what happens when a client simply initiates a full handshake. In that case there is no general need to invalidate an old ticket. TLS is quite capable of having two parallel sessions between any pair of communicating parties. However, as you indicate, you might want to explicitly terminate a session. As Vidya indicated, this requires server side state, though less than a session cache would require. > Right, that's as per 4346. However, 4507 says "When presenting a > ticket, the client MAY generate and include a Session ID in the TLS > ClientHello." Given that the client can change the session id, it > becomes difficult (not impossible as I initially thought) for the > server to track and invalidate old tickets. It's not difficult at all. You invalidate the ticket, not the session ID. The details are described in the SBR04 reference cited below. > But, perhaps as you say, > this is generally not an issue in practice. If the ticket lifetime is > generally short enough, it is probably not a big deal (although it > would have been nice to have stated it in 4507). Well, here's what 4507 says: 5.1. Invalidating Sessions The TLS specification requires that TLS sessions be invalidated when errors occur. [CSSC] discusses the security implications of this in detail. In the analysis in this paper, failure to invalidate sessions does not pose a security risk. This is because the TLS handshake uses a non-reversible function to derive keys for a session so information about one session does not provide an advantage to attack the master secret or a different session. If a session invalidation scheme is used, the implementation should verify the integrity of the ticket before using the contents to invalidate a session to ensure that an attacker cannot invalidate a chosen session. [CSSC] is a reference to SBR04, which provides a fairly detailed analysis of a variety of different ticket revocation schemes. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 13 21:57:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5vY8-0002k1-Oe; Sat, 13 Jan 2007 21:56:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5vY6-0002jr-QG for tls@ietf.org; Sat, 13 Jan 2007 21:56:47 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5vY5-0000Yn-Et for tls@ietf.org; Sat, 13 Jan 2007 21:56:46 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0E2uhjp031602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 13 Jan 2007 18:56:44 -0800 Received: from [10.50.76.70] (qconnect-10-50-76-70.qualcomm.com [10.50.76.70]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0E2ugoZ005801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Jan 2007 18:56:43 -0800 Message-ID: <45A99B9E.8060208@qualcomm.com> Date: Sat, 13 Jan 2007 18:55:26 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Question on Stateless TLS Session Resumption References: <863b6eh9v5.fsf@raman.networkresonance.com> <45A973A0.4000105@qualcomm.com> <86irfafo3j.fsf@raman.networkresonance.com> In-Reply-To: <86irfafo3j.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org No disagreements, just clarifying below: Eric Rescorla wrote: > Lakshminath Dondeti writes: > > > > Yes, as I said there are *two* issues. One issue is about what > happens when a client simply initiates a full handshake. In > that case there is no general need to invalidate an old ticket. > TLS is quite capable of having two parallel sessions between any > pair of communicating parties. This and key separation between sessions etc., are quite clear and there are no issues there. > > However, as you indicate, you might want to explicitly terminate > a session. As Vidya indicated, this requires server side state, > though less than a session cache would require. Right, this is what I was pointing out as "difficult" (for some degree of difficulty :) ). Either we need more state or more state plus some more computation to invalidate a ticket (I am thinking a hash computation), if the identity (session id) is not fixed. Yes, I took a quick at the relevant portions of the paper you cite, but that analysis assumes that there is a session id and assumes that the server has a blacklist of invalidated sessions. In any event, I understand this better now. Thanks for the clarifications. regards, Lakshminath _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 14 01:32:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ytt-0001vT-EA; Sun, 14 Jan 2007 01:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5yts-0001vD-Aw for tls@ietf.org; Sun, 14 Jan 2007 01:31:28 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5ytr-0003pf-0W for tls@ietf.org; Sun, 14 Jan 2007 01:31:28 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0B7141E8C28; Sat, 13 Jan 2007 22:31:26 -0800 (PST) To: Lakshminath Dondeti Subject: Re: [TLS] Question on Stateless TLS Session Resumption References: <863b6eh9v5.fsf@raman.networkresonance.com> <45A973A0.4000105@qualcomm.com> <86irfafo3j.fsf@raman.networkresonance.com> <45A99B9E.8060208@qualcomm.com> From: Eric Rescorla Date: Sat, 13 Jan 2007 22:31:25 -0800 In-Reply-To: <45A99B9E.8060208@qualcomm.com> (Lakshminath Dondeti's message of "Sat, 13 Jan 2007 18:55:26 -0800") Message-ID: <86bql2f7b6.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Lakshminath Dondeti writes: >> However, as you indicate, you might want to explicitly terminate >> a session. As Vidya indicated, this requires server side state, >> though less than a session cache would require. > > Right, this is what I was pointing out as "difficult" (for some degree > of difficulty :) ). Either we need more state or more state plus some > more computation to invalidate a ticket (I am thinking a hash > computation), if the identity (session id) is not fixed. Actually, the existence of the session ID doesn't change matters much at all. Whatever operations you would follow with the session ID you follow with the ticket. > Yes, I took > a quick at the relevant portions of the paper you cite, but that > analysis assumes that there is a session id and assumes that the > server has a blacklist of invalidated sessions. RFC 4507 has both a ticket and a session ID. BSR04 uses the ticket as the session ID. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 14 11:56:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68dq-0005BI-0f; Sun, 14 Jan 2007 11:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68do-0005B9-En for tls@ietf.org; Sun, 14 Jan 2007 11:55:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H68dl-0000j8-36 for tls@ietf.org; Sun, 14 Jan 2007 11:55:32 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0EGtRLL012573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 14 Jan 2007 08:55:28 -0800 Received: from [10.50.77.45] (qconnect-10-50-77-45.qualcomm.com [10.50.77.45]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0EGtQ9u024469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Jan 2007 08:55:27 -0800 (PST) Message-ID: <45AA6033.9020407@qualcomm.com> Date: Sun, 14 Jan 2007 08:54:11 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Question on Stateless TLS Session Resumption References: <863b6eh9v5.fsf@raman.networkresonance.com> <45A973A0.4000105@qualcomm.com> <86irfafo3j.fsf@raman.networkresonance.com> <45A99B9E.8060208@qualcomm.com> <86bql2f7b6.fsf@raman.networkresonance.com> In-Reply-To: <86bql2f7b6.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Thanks Eric. I guess in my quick scan of your paper, I missed the "ticket" as the "session ID" aspect. In fact, hashing of the ticket as a substitute for session ID was what I was thinking about as the "extra" computation. Now the paper does talk about hashing the session ID, which makes sense now :). cheers, Lakshminath Eric Rescorla wrote: > Lakshminath Dondeti writes: >>> However, as you indicate, you might want to explicitly terminate >>> a session. As Vidya indicated, this requires server side state, >>> though less than a session cache would require. >> Right, this is what I was pointing out as "difficult" (for some degree >> of difficulty :) ). Either we need more state or more state plus some >> more computation to invalidate a ticket (I am thinking a hash >> computation), if the identity (session id) is not fixed. > > Actually, the existence of the session ID doesn't change matters > much at all. Whatever operations you would follow with the > session ID you follow with the ticket. > > >> Yes, I took >> a quick at the relevant portions of the paper you cite, but that >> analysis assumes that there is a session id and assumes that the >> server has a blacklist of invalidated sessions. > > RFC 4507 has both a ticket and a session ID. BSR04 uses the > ticket as the session ID. > > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 14 16:34:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6CyW-0003Vr-8s; Sun, 14 Jan 2007 16:33:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6CyU-0003Vm-Pj for tls@ietf.org; Sun, 14 Jan 2007 16:33:10 -0500 Received: from bay0-omc3-s21.bay0.hotmail.com ([65.54.246.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6CyQ-00055Y-5v for tls@ietf.org; Sun, 14 Jan 2007 16:33:10 -0500 Received: from hotmail.com ([65.55.131.20]) by bay0-omc3-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 14 Jan 2007 13:33:05 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Jan 2007 13:33:05 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV10.phx.gbl with DAV; Sun, 14 Jan 2007 21:33:04 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sun, 14 Jan 2007 13:33:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 14 Jan 2007 21:33:05.0393 (UTC) FILETIME=[938E3610:01C73823] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [TLS] The "other means" of controlling sessionids, master_secrets X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org concerning RFC 4507. The IESG appears to assert the following:- "SessionTicket TLS Extension [...] If the client possesses a ticket that it wants to use to resume a session, then it includes the ticket in the SessionTicket extension in the ClientHello. [...] [...]If the client is not prepared to receive a ticket in the NewSessionTicket handshake message then it MUST NOT include a SessionTicket extension unless it is sending a non-empty ticket it received through some other means from the server." [http://www.rfc-archive.org/getrfc.php?rfc=4507] So, I'm assuming (a) a ticket contains a wrapped master_secret (b) the last clause from above (other means), c) the TLS transport is EAP-TLS [rfc2716bis-06] cooperating with PPTP [RFC2637]. Lets now presume that there are 10 current TLS connection states in the client's cache, all duplicates of an active sessionid. Once a minute, they each perform a (keying material refresh) re-handshake citing their ticket generated by the server, and communicated on the n-1th handshake. (This "ticket" seems to be a variation of SSL3 fortezza_dms model for communicating (stateless) wrapped master_keys from the client endpoint to the loadbalancer) Lets also presume that it is conforming for TLS endpoints to NEVER NEED TO DO a "full handshake", to establish a given sessionid. That is, we exploited assumption (b). The assumption means that the sessionid name and the wrapped master_secret value are managed by some proprietary key distribution protocol tuned to the nature of the TLS transport, in question. Presumably in TLS1.2 the ciphersuite designer specifes a suitable KDF, similarly, to generate suitable amounts of keying material for the nature of the fragment transport. Presumably, a fatal alert on any one of those connections NO longer affects re-use of a sessionid on the others, given the sessionid is managed "by other means". All obligations for sessionid handling are borne by the client, AND these are set to comply with its (non-SSL) agreements with the server. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 01:53:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6LhX-0000MC-6f; Mon, 15 Jan 2007 01:52:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6LhV-0000M2-RY for tls@ietf.org; Mon, 15 Jan 2007 01:52:13 -0500 Received: from bay0-omc3-s37.bay0.hotmail.com ([65.54.246.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6LhT-0005vx-Fn for tls@ietf.org; Mon, 15 Jan 2007 01:52:13 -0500 Received: from hotmail.com ([65.55.131.17]) by bay0-omc3-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 14 Jan 2007 22:52:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Jan 2007 22:52:10 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV7.phx.gbl with DAV; Mon, 15 Jan 2007 06:52:08 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sun, 14 Jan 2007 22:52:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 06:52:10.0637 (UTC) FILETIME=[AE143BD0:01C73871] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [TLS] Re: The "other means" of controlling sessionids, master_secrets X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The following describes where I'm going one thought train, on this topic. In what follows, I may or may not be making a conforming usage of the ticket standard. This interpretation is a useful test of the spec, as from my reading I believe what I'm doing is (a) correct (b) intended. If folks think it's not, the RFC needs some work. Whilst I'm definitely not exploiting the ticketing mechanism for its stated raison d'etre, I do believe I'm 100% conforming in what follows:- Assume the "other means" noted in the standard is: a SAML2 protocol flow. The client http browser cooperates with an IDP saml-endpoint (at his/her favorite portal (google.com, live.com, enterprise.com, society.org ...)), and the target website in the server farm cooperates with an SP saml-endpoint (a service appliance adjacent to the load balancer). Lets assume the saml-endpoints on IDP and SP participate in federated identity sharing, and use XML Encryption to share attributes (including a master_secret) defined in an attribute contract. Also assume that, incidentally, the XML DigSigs used in SAML flow achieve webSSO, per the SAML POST profile and metadata (certs, trust anchors etc) are all set up via the controlling trust model. Now, lets assume that upon finally being redirected to the the app server using an https URL (where said server is deep in data center's access layer), said site now cooperates "locally" with the "ticket-enabled" SSL-offloading load balancer in the aggregation layer of its data center. Cooperation includes at least...delegating control of the master_secret retrieved from the SAML messages to the load balancer, so it can wrap it, and share it henceforth - using the ticket regime. Another cooperation could reverse the relationship between load balancer and app server, in which certain state information from the SSL session could be relayed to the app server (as an inserted HTTP header, for example). Using the SAML2 Attribute Query now, this state information could be communicated to the IDP site in a custom query type (using signed XML messages). In this way, the SP and IDP endpoints could both share certain information from the SSL stream that their SAML trust model calls for mutual rights to audit. I think I can do all this today, just exploiting the architecture of TLS1.0 and tickets. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 09:03:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6SPg-0002LA-B5; Mon, 15 Jan 2007 09:02:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6SPe-0002L2-Mk for tls@ietf.org; Mon, 15 Jan 2007 09:02:14 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6SPd-0002Fb-9q for tls@ietf.org; Mon, 15 Jan 2007 09:02:14 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA16306; Mon, 15 Jan 2007 15:01:56 +0100 (MEZ) From: Martin Rex Message-Id: <200701151401.PAA27837@uw1048.wdf.sap.corp> To: ekr@networkresonance.com Date: Mon, 15 Jan 2007 15:01:56 +0100 (MET) In-Reply-To: <863b6eh9v5.fsf@raman.networkresonance.com> from "Eric Rescorla" at Jan 13, 7 01:53:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tls@ietf.org Subject: [TLS] when is it ok to resume a cached SSL/TLS session X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > Yes, it's discussed extensively in the SBR04 paper on Client-Side > Session Caching. > > Shacham, H., Boneh, D., and E. Rescorla, "Client-side > caching for TLS", Transactions on Information and System > Security (TISSEC) , Volume 7, Issue 4, November 2004. Since you didn't include an URL, I assume this isn't available online anwhere. We have just been reported by one of our customers what I consider a bug in the client side SSL/TLS session cache of a popular Browser, failing on a flawed assumption. Scenario: A host running two seperate SSL/TLS secured services (a J2EE- and a C/C++-built serice) on different TCP-Ports using seperate SSL/TLS (one is pure Java, the other pure C) implementations that differ in the highest supported protocol version. The Service with the newer implementation is the "main service" or entry point, and it sometimes generates URLs referencing the other service (same host, different TCP-Port) with the older SSL/TLS implementation. The problem: The popular browser, when trying to access the older SSL/TLS implementation on a different TCP-Port is sending a session ID from the newer SSL/TLS implementation, apparently trying to resume an existing SSL session in the client-side session cache. The server doesn't recognize that session and replies with a Server Hello containing his highest protocol version, plus plus server certificate message plus client cert request plus server hello done. The popular Web Browser closes the network connection without sending any kind of SSL alert and shows "Page cannot be displayed" to the user. I firmly believe that this is a conceptual flaw on the client side, making a flawed assumption about when a cached SSL session can be expected to be resumable. The problem is not with the client sending an existing session ID, it is about dealing with the servers reply during the SSL/TLS handshake. - a server on a different port might not be sharing the session cache with the other - a server on a different port migt be using an entirely different SSL/TLS protocol implementation supporting different protocol versions and extensions - a server on a different port might be using a seperate server cert - a server on a different port might be sending/using an independent list of trusted CAs in a client certificate request In our customers case, the Browser might be aborting thinking that the a version rollback attack is being performed, but honestly, I don't know what the problem is. The browsers SSL implementation is extremely poor/broken when reporting errors. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 09:35:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Sva-0004OS-Fq; Mon, 15 Jan 2007 09:35:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6SvZ-0004OL-3G for tls@ietf.org; Mon, 15 Jan 2007 09:35:13 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6SvX-0006Yu-Ai for tls@ietf.org; Mon, 15 Jan 2007 09:35:12 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id PAA12383 for ; Mon, 15 Jan 2007 15:35:05 +0100 (MEZ) From: Martin Rex Message-Id: <200701151435.PAA28213@uw1048.wdf.sap.corp> Orig-To: ekr@networkresonance.com To: tls@ietf.org Date: Mon, 15 Jan 2007 15:01:56 +0100 (MET) In-Reply-To: <863b6eh9v5.fsf@raman.networkresonance.com> from "Eric Rescorla" at Jan 13, 7 01:53:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 2.3 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tls@ietf.org Subject: [TLS] when is it ok to resume a cached SSL/TLS session X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > Yes, it's discussed extensively in the SBR04 paper on Client-Side > Session Caching. > > Shacham, H., Boneh, D., and E. Rescorla, "Client-side > caching for TLS", Transactions on Information and System > Security (TISSEC) , Volume 7, Issue 4, November 2004. Since you didn't include an URL, I assume this isn't available online anwhere. We have just been reported by one of our customers what I consider a bug in the client side SSL/TLS session cache of a popular Browser, failing on a flawed assumption. Scenario: A host running two seperate SSL/TLS secured services (a J2EE- and a C/C++-built serice) on different TCP-Ports using seperate SSL/TLS (one is pure Java, the other pure C) implementations that differ in the highest supported protocol version. The Service with the newer implementation is the "main service" or entry point, and it sometimes generates URLs referencing the other service (same host, different TCP-Port) with the older SSL/TLS implementation. The problem: The popular browser, when trying to access the older SSL/TLS implementation on a different TCP-Port is sending a session ID from the newer SSL/TLS implementation, apparently trying to resume an existing SSL session in the client-side session cache. The server doesn't recognize that session and replies with a Server Hello containing his highest protocol version, plus plus server certificate message plus client cert request plus server hello done. The popular Web Browser closes the network connection without sending any kind of SSL alert and shows "Page cannot be displayed" to the user. I firmly believe that this is a conceptual flaw on the client side, making a flawed assumption about when a cached SSL session can be expected to be resumable. The problem is not with the client sending an existing session ID, it is about dealing with the servers reply during the SSL/TLS handshake. - a server on a different port might not be sharing the session cache with the other - a server on a different port migt be using an entirely different SSL/TLS protocol implementation supporting different protocol versions and extensions - a server on a different port might be using a seperate server cert - a server on a different port might be sending/using an independent list of trusted CAs in a client certificate request In our customers case, the Browser might be aborting thinking that the a version rollback attack is being performed, but honestly, I don't know what the problem is. The browsers SSL implementation is extremely poor/broken when reporting errors. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 10:38:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TuV-0004py-TD; Mon, 15 Jan 2007 10:38:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TuU-0004pt-PD for tls@ietf.org; Mon, 15 Jan 2007 10:38:10 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6TuR-0006Yo-Co for tls@ietf.org; Mon, 15 Jan 2007 10:38:10 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id A77285C01E; Mon, 15 Jan 2007 07:46:00 -0800 (PST) To: martin.rex@sap.com In-reply-to: Your message of "Mon, 15 Jan 2007 15:01:56 +0100." <200701151401.PAA27837@uw1048.wdf.sap.corp> X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 15 Jan 2007 07:38:04 -0800 From: Eric Rescorla Message-Id: <20070115154600.A77285C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@ietf.org Subject: [TLS] Re: when is it ok to resume a cached SSL/TLS session X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > Eric Rescorla wrote: > > > > Yes, it's discussed extensively in the SBR04 paper on Client-Side > > Session Caching. > > > > Shacham, H., Boneh, D., and E. Rescorla, "Client-side > > caching for TLS", Transactions on Information and System > > Security (TISSEC) , Volume 7, Issue 4, November 2004. > > Since you didn't include an URL, I assume this isn't available online > anwhere. No, I just forgot. http://www.hovav.net/dist/sslex.pdf > We have just been reported by one of our customers what I consider > a bug in the client side SSL/TLS session cache of a popular Browser, > failing on a flawed assumption. > > Scenario: A host running two seperate SSL/TLS secured services > (a J2EE- and a C/C++-built serice) on different TCP-Ports using > seperate SSL/TLS (one is pure Java, the other pure C) implementations > that differ in the highest supported protocol version. > > The Service with the newer implementation is the "main service" > or entry point, and it sometimes generates URLs > referencing the other service (same host, different TCP-Port) > with the older SSL/TLS implementation. > > > The problem: The popular browser, when trying to access the older > SSL/TLS implementation on a different TCP-Port is sending a > session ID from the newer SSL/TLS implementation, apparently trying > to resume an existing SSL session in the client-side session cache. > > The server doesn't recognize that session and replies with > a Server Hello containing his highest protocol version, plus > plus server certificate message plus client cert request plus > server hello done. The popular Web Browser closes the network > connection without sending any kind of SSL alert and shows > "Page cannot be displayed" to the user. > > > I firmly believe that this is a conceptual flaw on the client > side, making a flawed assumption about when a cached SSL session > can be expected to be resumable. ISTM that there are two issues here: 1. Whether the client should have offered asession ID. 2. Whether it should have choked when the server refused. Without taking a position on the first, which I think is tricky, the client should definitely not have choked. Servers can always refuse to accept a resumption. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 11:06:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ULu-0006Ar-Az; Mon, 15 Jan 2007 11:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ULt-0006Am-6V for tls@ietf.org; Mon, 15 Jan 2007 11:06:29 -0500 Received: from bay0-omc3-s34.bay0.hotmail.com ([65.54.246.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ULq-0001T3-Ke for tls@ietf.org; Mon, 15 Jan 2007 11:06:29 -0500 Received: from hotmail.com ([65.55.131.16]) by bay0-omc3-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 08:06:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 08:06:25 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV6.phx.gbl with DAV; Mon, 15 Jan 2007 16:06:24 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <20070115154600.A77285C01E@laser.networkresonance.com> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 08:06:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 16:06:25.0754 (UTC) FILETIME=[1BAC63A0:01C738BF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> The server doesn't recognize that session and replies >> with >> a Server Hello containing his highest protocol version, >> plus >> plus server certificate message plus client cert request >> plus >> server hello done. The popular Web Browser closes the >> network >> connection without sending any kind of SSL alert and >> shows >> "Page cannot be displayed" to the user. >> >> >> I firmly believe that this is a conceptual flaw on the >> client >> side, making a flawed assumption about when a cached SSL >> session >> can be expected to be resumable. > > ISTM that there are two issues here: > > 1. Whether the client should have offered asession ID. > 2. Whether it should have choked when the server refused. > > Without taking a position on the first, which I think is > tricky, > the client should definitely not have choked. Servers can > always > refuse to accept a resumption. > > -Ekr I reasoned differently, because this is an https context - there is thus a URL resolver involved. The validity of a secure URL is not the same as the validity of an SSL-named layer 4 TCP port (or SSL-named PPP tunnel connection,....) At the SSL layer, the client sought a session resumption from a named layer 4 port. Session resumption means that the URL resolver at the https layer, however, is based on the client's connection state , not the host/port parsing. This includes the binding of URLs used in session creation, and the URL used in connection establishment (which are allowed to differ) IN the cited case, a server responding from a given layer 4 port of the second URL refused to resume a session (for some reason, like it didn't share session state records with another implementation). It then correctly engaged in a full handshake (with unusual custom pipelining of full handshake messages). The client is entitled to reject the handshake, as in any full/partial rehandshake case. The client uses the conforming option to close the TLS Transport (TCP) rather than perform a close. This is reasonable, given the URL resource showed no knowledge of the sessionid/keying material. --- I exploit the SSL architecture myself, sending server HelloRequests to my clients which respond with a clientHello (with special data in the time/nonce), a server Hello is similarly sent with similar custom time/nonce, which causes the client to finally issue a "sorry no"... alert, non-fatal. My special data happens to be time-synced OTPs (with CR capability, beyond STD 61), generated by a USB smartcard device. Given the flow is occurring over the current connection state (which is running mac'ed in my cipher suite, and each fragment gets DOA semantics from the confidentiality service) I'm adding timing signals to the SSL record_layer essentially. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 11:18:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UWh-0003Ra-TO; Mon, 15 Jan 2007 11:17:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UWg-0003RS-Gw for tls@ietf.org; Mon, 15 Jan 2007 11:17:38 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6UWe-0002ww-HC for tls@ietf.org; Mon, 15 Jan 2007 11:17:38 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C6C531E8C28; Mon, 15 Jan 2007 08:17:35 -0800 (PST) To: Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session References: <20070115154600.A77285C01E@laser.networkresonance.com> From: Eric Rescorla Date: Mon, 15 Jan 2007 08:17:35 -0800 In-Reply-To: (home pw's message of "Mon, 15 Jan 2007 08:06:23 -0800") Message-ID: <86ac0ke02o.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: >>> The server doesn't recognize that session and replies with >>> a Server Hello containing his highest protocol version, plus >>> plus server certificate message plus client cert request plus >>> server hello done. The popular Web Browser closes the network >>> connection without sending any kind of SSL alert and shows >>> "Page cannot be displayed" to the user. >>> >>> >>> I firmly believe that this is a conceptual flaw on the client >>> side, making a flawed assumption about when a cached SSL session >>> can be expected to be resumable. >> >> ISTM that there are two issues here: >> >> 1. Whether the client should have offered asession ID. >> 2. Whether it should have choked when the server refused. >> >> Without taking a position on the first, which I think is tricky, >> the client should definitely not have choked. Servers can always >> refuse to accept a resumption. >> >> -Ekr > > I reasoned differently, because this is an https context - > there is thus a URL resolver involved. The validity of a secure URL is > not the same as the validity of an SSL-named layer 4 TCP port (or > SSL-named PPP tunnel connection,....) > > At the SSL layer, the client sought a session resumption from a named > layer 4 port. Session resumption means that the URL resolver at the > https layer, however, is based on the client's connection state , not > the host/port parsing. This includes the binding of URLs used in > session creation, and the URL used in connection establishment (which > are allowed to differ) > > IN the cited case, a server responding from a given layer 4 port of > the second URL refused to resume a session (for some reason, like it > didn't share session state records with another implementation). It > then correctly engaged in a full handshake (with unusual custom > pipelining of full handshake messages). > > The client is entitled to reject the handshake, as in any full/partial > rehandshake case. The client uses the conforming option to close the > TLS Transport (TCP) rather than perform a close. This is reasonable, > given the URL resource showed no knowledge of the sessionid/keying > material. Peter, TLS session IDs do not come with any guarantee that the server will actually honor a resumption request. The server may implement any session cache policy it chooses. Therefore the client *must* be prepared for the server to refuse resumption. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 12:06:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VHP-0007Oj-53; Mon, 15 Jan 2007 12:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VHO-0007Oe-30 for tls@ietf.org; Mon, 15 Jan 2007 12:05:54 -0500 Received: from bay0-omc3-s14.bay0.hotmail.com ([65.54.246.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6VHH-0003gi-1Z for tls@ietf.org; Mon, 15 Jan 2007 12:05:54 -0500 Received: from hotmail.com ([65.55.131.17]) by bay0-omc3-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 09:05:46 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 09:05:45 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV7.phx.gbl with DAV; Mon, 15 Jan 2007 17:05:44 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <20070115154600.A77285C01E@laser.networkresonance.com> <86ac0ke02o.fsf@raman.networkresonance.com> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 09:05:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 17:05:45.0978 (UTC) FILETIME=[65BB75A0:01C738C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Peter, > > TLS session IDs do not come with any guarantee that the > server will > actually honor a resumption request. The server may > implement any > session cache policy it chooses. Therefore the client > *must* be > prepared for the server to refuse resumption. > > -Ekr So the only thing we are disagreeing on is the definition of "must be prepared". You say choked, I say graceful fail. So... we are back to the reasserting the old adage: the TLS standard DOES NOT constrain or recommend on how TLS Transport connections are handled in general. The words in TLS could not be much clearer. https is of course both an application and a "usage model" for TLS, some SSL-related parts of which folks have attempted to create a standard profile as regard alert handling. I fail to see why the UI behavior of a multi-URL-protocol browser should be different for https vs other URL protocols. Furthermore, a non-Navigator-style web client is even less constrained, because it may a moniker resolver aswell as a URL resolver built into the application. We all know wininet has different https behavior to IE, which is yet different to the MSN Explorer. We all know Navigator in turn has "unique" security semantics concerning its SSL session duplication , and a "unique" trust access model to cookies by child windows etc... I have no expectation that navigator's client-side sessionid caching policy (for https resolution) is the same of the other 3 examples, I gave! If the particular browser experience design has established (via a combined security vs usability tradeoff analysis) a certain practice concerning how it visualizes and handles (connection) failure cases (cannot "connect" to a resource, ultimately) when using all the NON-https URL protocols why should it vary this view ...for the session resumption exception on the https URL? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 12:12:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VNX-0003OQ-PC; Mon, 15 Jan 2007 12:12:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VNW-0003OK-Te for tls@ietf.org; Mon, 15 Jan 2007 12:12:14 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6VNU-0004h7-Jr for tls@ietf.org; Mon, 15 Jan 2007 12:12:14 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1835F1E8C28; Mon, 15 Jan 2007 09:12:12 -0800 (PST) To: Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session References: <20070115154600.A77285C01E@laser.networkresonance.com> <86ac0ke02o.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 15 Jan 2007 09:12:11 -0800 In-Reply-To: (home pw's message of "Mon, 15 Jan 2007 09:05:42 -0800") Message-ID: <86lkk4ciz8.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: >> Peter, >> >> TLS session IDs do not come with any guarantee that the server will >> actually honor a resumption request. The server may implement any >> session cache policy it chooses. Therefore the client *must* be >> prepared for the server to refuse resumption. >> >> -Ekr > > So the only thing we are disagreeing on is the definition of "must be > prepared". > > You say choked, I say graceful fail. No, I don't agree with this analysis. The server being unwilling to resume a session is normal behavior. The TLS state machine explicitly handles such cases. Implementations which choke rather than doing a full handshake are broken. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 12:27:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VcK-0000Nt-1J; Mon, 15 Jan 2007 12:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VcI-0000Nm-G5 for tls@ietf.org; Mon, 15 Jan 2007 12:27:30 -0500 Received: from bay0-omc1-s20.bay0.hotmail.com ([65.54.246.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6VcF-0006m8-Jd for tls@ietf.org; Mon, 15 Jan 2007 12:27:30 -0500 Received: from hotmail.com ([65.55.131.27]) by bay0-omc1-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 09:27:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 09:27:26 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV17.phx.gbl with DAV; Mon, 15 Jan 2007 17:27:26 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <20070115154600.A77285C01E@laser.networkresonance.com><86ac0ke02o.fsf@raman.networkresonance.com> <86lkk4ciz8.fsf@raman.networkresonance.com> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 09:27:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 17:27:26.0663 (UTC) FILETIME=[6D003D70:01C738CA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > No, I don't agree with this analysis. The server being > unwilling > to resume a session is normal behavior. The TLS state > machine > explicitly handles such cases. Implementations which choke > rather than doing a full handshake are broken. > > -Ekr Perhaps the TLS state machine changed from the SSL state machine ? I did notice in your book how you tied your concept of the state transitions of an implementation to the TCP state machine, something I don't do. Its like we said for trust chains: regardless of what a server sends, what client APPLICATION uses is up to it. it can ignore the server-supplied trust chain, if it chooses. The same goes for accessing client-side crypto. Jus because a server (which has not proved knowledge of secrets from a TLS-connection state) seeks me to access my crypto device DOES NOT MEAN I DO IT. Im perfectly entitled to have a product design that seeks the user to enter a smartcard at that point; and close MY connection attempt if the user does not present it in some time. We are now squarely arguing over:- One advantage of TLS is that it is application protocol independent. Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. and then (note the final clause):- If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation must receive the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation may choose to close the transport without waiting for the responding close_notify. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 12:41:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VpV-0005ko-4d; Mon, 15 Jan 2007 12:41:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VpT-0005kj-I6 for tls@ietf.org; Mon, 15 Jan 2007 12:41:07 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6VpS-0000L3-6U for tls@ietf.org; Mon, 15 Jan 2007 12:41:07 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5383E1E8C28; Mon, 15 Jan 2007 09:41:05 -0800 (PST) To: Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session References: <20070115154600.A77285C01E@laser.networkresonance.com> <86ac0ke02o.fsf@raman.networkresonance.com> <86lkk4ciz8.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 15 Jan 2007 09:41:05 -0800 In-Reply-To: (home pw's message of "Mon, 15 Jan 2007 09:27:25 -0800") Message-ID: <86vej8b32m.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: >> No, I don't agree with this analysis. The server being unwilling >> to resume a session is normal behavior. The TLS state machine >> explicitly handles such cases. Implementations which choke >> rather than doing a full handshake are broken. >> >> -Ekr > > Perhaps the TLS state machine changed from the SSL state machine ? No, it didn't. This feature has been there since SSLv3 (and in variant, since SSLv2). > Its like we said for trust chains: regardless of what a server sends, > what client APPLICATION uses is up to it. it can ignore the > server-supplied trust chain, if it chooses. > > The same goes for accessing client-side crypto. Jus because a server > (which has not proved knowledge of secrets from a TLS-connection > state) seeks me to access my crypto device DOES NOT MEAN I DO IT. Im > perfectly entitled to have a product design that seeks the user to > enter a smartcard at that point; and close MY connection attempt if > the user does not present it in some time. > > We are now squarely arguing over:- > > One advantage of TLS is that it is application protocol independent. > Higher level protocols can layer on top of the TLS Protocol > transparently. The TLS standard, however, does not specify how > protocols add security with TLS; the decisions on how to initiate > TLS > handshaking and how to interpret the authentication certificates > exchanged are left up to the judgment of the designers and > implementors of protocols which run on top of TLS. > > and then (note the final clause):- > > If the application protocol using TLS provides that any data may be > carried over the underlying transport after the TLS connection is > closed, the TLS implementation must receive the responding > close_notify alert before indicating to the application layer that > the TLS connection has ended. If the application protocol will not > transfer any additional data, but will only close the underlying > transport connection, then the implementation may choose to close > the > transport without waiting for the responding close_notify. No part > of > this standard should be taken to dictate the manner in which a usage > profile for TLS manages its data transport, including when > connections are opened or closed. No, I don't agree that we're arguing over this at all. We're arguing about whether it's appropriate to treat failure to resume as an error. It's not. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 13:04:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WBV-0003sn-5m; Mon, 15 Jan 2007 13:03:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WBT-0003sL-Qg for tls@ietf.org; Mon, 15 Jan 2007 13:03:51 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6WBQ-00041v-Ry for tls@ietf.org; Mon, 15 Jan 2007 13:03:51 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA11476; Mon, 15 Jan 2007 19:03:39 +0100 (MEZ) From: Martin Rex Message-Id: <200701151803.TAA01170@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session To: ekr@networkresonance.com Date: Mon, 15 Jan 2007 19:03:39 +0100 (MET) In-Reply-To: <86lkk4ciz8.fsf@raman.networkresonance.com> from "Eric Rescorla" at Jan 15, 7 09:12:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > writes: > > > > Eric Rescorla wrote: > >> TLS session IDs do not come with any guarantee that the server will > >> actually honor a resumption request. The server may implement any > >> session cache policy it chooses. Therefore the client *must* be > >> prepared for the server to refuse resumption. > >> > > > > So the only thing we are disagreeing on is the definition of "must be > > prepared". > > > > You say choked, I say graceful fail. > > No, I don't agree with this analysis. The server being unwilling > to resume a session is normal behavior. The TLS state machine > explicitly handles such cases. Implementations which choke > rather than doing a full handshake are broken. I fully agree with Eric that a client MUST deal gracefully with a server that does not resume a proposes SSL session (ID) for whatever reason. The particular problem in the scenario that I listed might be that the client, by retrieving a cached session from its cache thought he had several parameter (including the protocol version) already established and treated the response from the server (who didn't resume as proposed) probably more like a renegotiation rather than a new handshake, and therefore might have considered the unavailablility of the previous higher protocol version a rollback attack. The client-side SSL session cache can not be implemented "transparently" in the TLS implementation, it needs significant extra information from the application in order to know whether and which cached SSL session might be resumed. Think about a client-side proxy (CONNECT), where the layer above TLS must perform the CONNECT handshake with the proxy, and where the network target IP and TCP-Port will be the same for all non-local addresses. There, the decision whether and which SSL session cache entry might be tried for resumption will have to be derived from the hostname:port from the URL (which is also used for server endpoint identification). In our customer's scenario, no proxy is involved, so the different endpoint is visible on both, the socket and the URL. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 13:58:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6X1o-0001Q3-Js; Mon, 15 Jan 2007 13:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6X1n-0001Px-Dl for tls@ietf.org; Mon, 15 Jan 2007 13:57:55 -0500 Received: from bay0-omc2-s27.bay0.hotmail.com ([65.54.246.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6X1l-0002LV-Nw for tls@ietf.org; Mon, 15 Jan 2007 13:57:55 -0500 Received: from hotmail.com ([65.55.131.13]) by bay0-omc2-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 10:57:53 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 10:57:52 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV3.phx.gbl with DAV; Mon, 15 Jan 2007 18:57:51 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: , References: <200701151803.TAA01170@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 10:57:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 18:57:52.0915 (UTC) FILETIME=[0F4C9630:01C738D7] X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> > You say choked, I say graceful fail. >> >> No, I don't agree with this analysis. The server being >> unwilling >> to resume a session is normal behavior. The TLS state >> machine >> explicitly handles such cases. Implementations which >> choke >> rather than doing a full handshake are broken. > > I fully agree with Eric that a client MUST deal gracefully > with > a server that does not resume a proposes SSL session (ID) > for > whatever reason. Show me the text in the standard that says MUST (or even half hints MUST from the English wording). Tell me it MUST apply to EAP-TLS, too. More importantly, tell me what "appropriate" and "graceful" then mean, for packets on the wire. Tell me what the server MUST do, if the client does not comply. Your both making this out to be security- or interoperability- critical (it's a MUST, Peter!!) Eric is clear that this is not a new concept (for novel discussion); but an ancient one. It must be pretty obviously disclosed, or have been improved (by now) due to the years of text review. Now, for my part, I already pointed out text that says, I the implementer have 100% control over open and closing connections. NOTHING IN THIS STANDARD SHALL ... Now, I will also listen to any decent appeal. I'm willing to be convinced (just show me some half reasonable basis from the standard), as the text I'm quoting was admittedly highly contextualized. But, it was also an adamant, general claim. So, give me some SSl2, SSL3, TLS1.x text (not argument) to weigh against it. Concerning the evidence:- "The particular problem in the scenario that I listed might be that the client, by retrieving a cached session from its cache thought he had several parameter (including the protocol version) already established and treated the response from the server (who didn't resume as proposed) probably more like a renegotiation rather than a new handshake, and therefore might have considered the unavailablility of the previous higher protocol version a rollback attack." VERY LIKELY! This is in MY purview - as a implementer - to decide; Martin, you are making my point for me. My implementations don't support ANY of the fallback practices, either, by default! Now that implementation may or may not have a good attack signature algorithm; perhaps its intentionally non-conforming in its TLS handling of protocol version negotiation, even. But, my only point is: its for EITHER PEER to decide (right or wrong) on whether it closes a connection abruptly. We cannot assume otherwise in any case, since the IDS may interdict packet flow anyways, for its own reasons. E.g. If you even propose NullWithNull in a non private-mode EAP-TLS handshake, you will be dropped by my IDS. Period. Now if I'm am even half convinced that the standard specifies what you both assert, I will properly eat crow, but I will not actually change my default security policy: Ill simply disclose non-conforming (default) behavior. Gaining Interoperability in open systems OFTEN DOES demand a lowering of absolute thesh-holds - but at the user's discretion. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 14:05:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6X96-0005tk-7j; Mon, 15 Jan 2007 14:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6X94-0005tc-NC for tls@ietf.org; Mon, 15 Jan 2007 14:05:26 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6X93-0003E9-BT for tls@ietf.org; Mon, 15 Jan 2007 14:05:26 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id A55D71E8C28; Mon, 15 Jan 2007 11:05:24 -0800 (PST) To: Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session References: <200701151803.TAA01170@uw1048.wdf.sap.corp> From: Eric Rescorla Date: Mon, 15 Jan 2007 11:05:24 -0800 In-Reply-To: (home pw's message of "Mon, 15 Jan 2007 10:57:50 -0800") Message-ID: <86tzys9kln.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: >>> > You say choked, I say graceful fail. >>> >>> No, I don't agree with this analysis. The server being unwilling >>> to resume a session is normal behavior. The TLS state machine >>> explicitly handles such cases. Implementations which choke >>> rather than doing a full handshake are broken. >> >> I fully agree with Eric that a client MUST deal gracefully with >> a server that does not resume a proposes SSL session (ID) for >> whatever reason. > > > Show me the text in the standard that says MUST (or even half hints > MUST from the English wording). Tell me it MUST apply to EAP-TLS, > too. More importantly, tell me what "appropriate" and "graceful" then > mean, for packets on the wire. Tell me what the server MUST do, if the > client does not comply. Your both making this out to be security- or > interoperability- critical (it's a MUST, Peter!!) > > Eric is clear that this is not a new concept (for novel discussion); > but an ancient one. It must be pretty obviously disclosed, or have > been improved (by now) due to the years of text review. > > Now, for my part, I already pointed out text that says, I the > implementer have 100% control over open and closing > connections. NOTHING IN THIS STANDARD SHALL ... RFC 4346 S 7.3. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send change cipher spec messages and proceed directly to finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake. In other words, refused session resumptions are totally normal behavior. Clients which treat them as anomalous are confused. Yes, a client can terminate the connection at any time and for any reason, including that it doesn't like the phase of the moon, but that doesn't make the assumption that a server will always resume a session---presenting an error to the user if it doesn't---any less insane. No such error occurred. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 14:23:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XQH-0000oS-5g; Mon, 15 Jan 2007 14:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XQF-0000nJ-Aa for tls@ietf.org; Mon, 15 Jan 2007 14:23:11 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6XQC-0005LI-Qz for tls@ietf.org; Mon, 15 Jan 2007 14:23:11 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA25914; Mon, 15 Jan 2007 20:23:01 +0100 (MEZ) From: Martin Rex Message-Id: <200701151923.UAA02162@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session To: home_pw@msn.com Date: Mon, 15 Jan 2007 20:23:00 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 15, 7 10:57:50 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > >> > You say choked, I say graceful fail. > >> > >> No, I don't agree with this analysis. The server being > >> unwilling > >> to resume a session is normal behavior. The TLS state > >> machine > >> explicitly handles such cases. Implementations which > >> choke > >> rather than doing a full handshake are broken. > > > > I fully agree with Eric that a client MUST deal gracefully > > with > > a server that does not resume a proposes SSL session (ID) > > for > > whatever reason. > > > Show me the text in the standard that says MUST (or even > half hints MUST from the English wording). Tell me it MUST > apply to EAP-TLS, too. More importantly, tell me what > "appropriate" and "graceful" then mean, for packets on the > wire. Tell me what the server MUST do, if the client does > not comply. Your both making this out to be security- or > interoperability- critical (it's a MUST, Peter!!) I think it is acceptable for a client to have a certain level of expectation about the servers characteristics for the exact same target endpoint (host:port), but not for a different one on the same host. Especially in the real world of NATs. It is an implied MUST, not one that is spelled out, based on common sense and established practices. Where in the spec do you find an indication that a client may blindy assume that all processes on one host will share even the most valuable secrets, like credentials and an SSL session cache. In the (Berkeley) Sockets interface there is a tradition that a server process opens a listener Socket and keeps accepting connections on this sockets for the lifetime of the process. Different server processes traditionally listen on different TCP and UDP ports, and it is a longstanding security practice to not have each and every service running with full system privileges. SSL is an extension to the (Berkeley) Socket interface and has basically inherited these traditions. > > Concerning the evidence:- > > "The particular problem in the scenario that I listed might > be that the client, by retrieving a cached session from its > cache thought he had several parameter (including the protocol > version) already established and treated the response from the server > (who didn't resume as proposed) probably more like a renegotiation > rather than a new handshake, and therefore might have considered > the unavailablility of the previous higher protocol version > a rollback attack." > > VERY LIKELY! This is in MY purview - as a implementer - to > decide; Martin, you are making my point for me. My > implementations don't support ANY of the fallback practices, > either, by default! I think it is clear from the protocol handshake and the state machine that there is a significant difference between a server not resuming a cached session and an established session doing a renegotiation. For the denied resume, there is no agreement on a common previous session state, while for a renegitiation request, there exists common agreed-upon session state. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 14:35:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XbZ-0000Q9-O8; Mon, 15 Jan 2007 14:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XbX-0000Px-TU for tls@ietf.org; Mon, 15 Jan 2007 14:34:51 -0500 Received: from bay0-omc2-s38.bay0.hotmail.com ([65.54.246.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6XbV-0006c9-JS for tls@ietf.org; Mon, 15 Jan 2007 14:34:51 -0500 Received: from hotmail.com ([65.55.131.19]) by bay0-omc2-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 11:34:49 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 11:34:48 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV9.phx.gbl with DAV; Mon, 15 Jan 2007 19:34:44 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <200701151803.TAA01170@uw1048.wdf.sap.corp> <86tzys9kln.fsf@raman.networkresonance.com> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 11:34:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 19:34:48.0900 (UTC) FILETIME=[38211040:01C738DC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > RFC 4346 S 7.3. > > If a match is found, and the server is willing to > re-establish the > connection under the specified session state, it will > send a > ServerHello with the same Session ID value. At this > point, both > client and server MUST send change cipher spec messages > and proceed > directly to finished messages. Once the > re-establishment is > complete, the client and server MAY begin to exchange > application > layer data. (See flow chart below.) If a Session ID > match is not > found, the server generates a new session ID and the TLS > client and > server perform a full handshake. > > In other words, refused session resumptions are totally > normal > behavior. Clients which treat them as anomalous are > confused. > > Yes, a client can terminate the connection at any time and > for > any reason, including that it doesn't like the phase of > the moon, > but that doesn't make the assumption that a server will > always > resume a session---presenting an error to the user if it > doesn't---any less insane. No such error occurred. This only partly reflects the case in question. I agree its the defining technical paragraph, tho (*). The server in Martin's case didn't find a match: that was the whole point. So, the last phrase controls. And, there is not a MUST in there. Ok. Lets conclude this, procedurally. Who agrees that TLS 1.2 shall be changed to:- "If a Session ID match is not found, the server generates a new session ID and the TLS client and server MUST perform a full handshake." With that settled, the next implementer get a nice, simple conformance case to test. No more interpretive arguments. ------ (*) I think THE FOLLOWING WAS BETTER WRITTEN personally " Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. " and lets not forget that maintaining a session resumption cache is OPTIONAL for a client in SSLv3. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 14:48:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Xog-0001m8-Tl; Mon, 15 Jan 2007 14:48:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Xof-0001lz-7e for tls@ietf.org; Mon, 15 Jan 2007 14:48:25 -0500 Received: from bay0-omc1-s17.bay0.hotmail.com ([65.54.246.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Xod-0008IU-Uu for tls@ietf.org; Mon, 15 Jan 2007 14:48:25 -0500 Received: from hotmail.com ([65.55.131.25]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 11:48:23 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 11:48:23 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV15.phx.gbl with DAV; Mon, 15 Jan 2007 19:48:20 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <200701151923.UAA02162@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 11:48:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 19:48:23.0067 (UTC) FILETIME=[1D6916B0:01C738DE] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org ----- Original Message ----- From: "Martin Rex" To: Cc: ; ; Sent: Monday, January 15, 2007 11:23 AM Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session > I think it is clear from the protocol handshake and the > state machine > that there is a significant difference between a server > not resuming > a cached session and an established session doing a > renegotiation. > For the denied resume, there is no agreement on a common > previous > session state, while for a renegitiation request, there > exists > common agreed-upon session state. Make your recommendation on the text change I proposed, for TLS 1.2. You have two choices really, given your (combined) arguments: SHOULD or MUST. If this is important enough, one of those two changes can be incorporated. It's a one word change. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 15:36:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YYb-0005bs-Vq; Mon, 15 Jan 2007 15:35:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YYZ-0005bm-Uw for tls@ietf.org; Mon, 15 Jan 2007 15:35:51 -0500 Received: from bay0-omc1-s34.bay0.hotmail.com ([65.54.246.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6YYX-0006aZ-BM for tls@ietf.org; Mon, 15 Jan 2007 15:35:51 -0500 Received: from hotmail.com ([65.55.131.13]) by bay0-omc1-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 12:35:48 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 12:35:48 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV3.phx.gbl with DAV; Mon, 15 Jan 2007 20:35:46 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: References: <200701151803.TAA01170@uw1048.wdf.sap.corp><86tzys9kln.fsf@raman.networkresonance.com> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 12:35:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 15 Jan 2007 20:35:48.0462 (UTC) FILETIME=[BD65E8E0:01C738E4] X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org OpenSSL, following the SHOULD recommendation Out of interest, in resumption procedures does OpenSSL (a) maintain the earliest expiry date of the certs in the partys' cert chains in the connection state(s), or (b) revalidate cert chains? If a server receives a client nonce that is later than the expiry data of the client cert INDICATED, is this a fatal alert case - even before handing the cert chain to the application? I assume not, under the "certs are opaque objects to SSL protocol machine" rule While invalidated sessionIds and expired/invalid certs DO NOT require either party to drop an ongoing TLS Connection, these same conditions CLEARLY control active session duplication, session resumption, and full handshakes. > If either party suspects that the session may have been > compromised, or that certificates may have expired or > been revoked, > it should force a full handshake. " _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 15 20:46:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6dON-0003IL-Qv; Mon, 15 Jan 2007 20:45:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6dOM-0003IG-OE for tls@ietf.org; Mon, 15 Jan 2007 20:45:38 -0500 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6dOK-0006fu-Ff for tls@ietf.org; Mon, 15 Jan 2007 20:45:37 -0500 Received: by wr-out-0506.google.com with SMTP id i4so1186551wra for ; Mon, 15 Jan 2007 17:45:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dZgOOmZRz4pv6eHtqfEPNfspxpx2ciA3TZETNN1eyl6Clziq19dLg9YhR23nYW9jbPoWslQhUB6xpbuJi2AI6bNod1BA/rKyPYXmtcp7lOs8kYSw27cPwBhyPpVue0ppdPsXPF0vXg5ab+OED2JogjRImj1GDWH3EfuhYDMPf9U= Received: by 10.90.113.18 with SMTP id l18mr3706743agc.1168911936127; Mon, 15 Jan 2007 17:45:36 -0800 (PST) Received: by 10.90.70.8 with HTTP; Mon, 15 Jan 2007 17:45:35 -0800 (PST) Message-ID: <6b9359640701151745h711a1701xb0612dfc280e509@mail.gmail.com> Date: Mon, 15 Jan 2007 18:45:35 -0700 From: "Kyle Hamilton" To: "home_pw@msn.com" Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070115154600.A77285C01E@laser.networkresonance.com> <86ac0ke02o.fsf@raman.networkresonance.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org An IP/port pair is sacred. This has two consequences: 1) session IDs should never be leaked beyond the sacred space into another sacred space, and 2) Even when resumption is requested, the server must be prepared for the client not to resume, and the client must be prepared for the server not to resume. When you 'exploit' the wording of any given publication, you end up with a situation such as what you describe: whether it's "choking" or "gracefully failing", the behavior is not what the end-user expects -- and since it's the end-user who must be built to, it's the end-user who determines what to describe it as, and the developers tasked with building to that end-user. "Be conservative in what you send." This has much more specific meaning in security-related protocols, because "...and liberal in what you accept" tends to reduce the security thereof. If a browser gets a "bad request" response from the server, does it instantly abort the connection and say "cannot connect"? No, it goes through its list of alternate protocols that it can possibly use. (more comments interspersed) On 1/15/07, home_pw@msn.com wrote: > > So the only thing we are disagreeing on is the definition of > "must be prepared". The session-resumption mechanism is explicitly optional negotiation acceleration in all of the drafts I've seen. This means that at all times a new connection is made and security parameters negotiated, it MUST be possible for either side to say "I want a full negotiation" and, regardless of the preference of the other side, get it. >From a user interface standpoint, throwing a fit when you don't get your way is a surefire way to get users not to use your software. > You say choked, I say graceful fail. tomato, tomahto. To the user of the software, it's the same damned thing. > I fail to see why the UI behavior of a multi-URL-protocol > browser should be different for https vs other URL > protocols. Furthermore, a non-Navigator-style web client is > even less constrained, because it may a moniker resolver > aswell as a URL resolver built into the application. We all > know wininet has different https behavior to IE, which is > yet different to the MSN Explorer. We all know Navigator in > turn has "unique" security semantics concerning its SSL > session duplication , and a "unique" trust access model to > cookies by child windows etc... I have no expectation that > navigator's client-side sessionid caching policy (for https > resolution) is the same of the other 3 examples, I gave! Which is why session resumption is an explicitly optional construct. > If the particular browser experience design has established > (via a combined security vs usability tradeoff analysis) a > certain practice concerning how it visualizes and handles > (connection) failure cases (cannot "connect" to a resource, > ultimately) when using all the NON-https URL protocols why > should it vary this view ...for the session resumption > exception on the https URL? How is "unable to connect" to a protocol-conforming server a usability decision? That's a usability failure. But, this is layers 6 and 7, not layer 4. Layers 6 and 7 build off of the capabilities of layer 4, and layer 4 provides its capabilities without reliance on information only available at higher layers. This is the only way protocol designers can keep themselves sane. TLS is "as transparent as possible". That doesn't mean that it can be wholly transparent. -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 16 00:02:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6gRq-0008PZ-Ee; Tue, 16 Jan 2007 00:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6gRp-0008O5-Gg for tls@ietf.org; Tue, 16 Jan 2007 00:01:25 -0500 Received: from bay0-omc1-s8.bay0.hotmail.com ([65.54.246.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6gRn-00087F-5I for tls@ietf.org; Tue, 16 Jan 2007 00:01:25 -0500 Received: from hotmail.com ([65.55.131.20]) by bay0-omc1-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 21:01:22 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 21:01:22 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV10.phx.gbl with DAV; Tue, 16 Jan 2007 05:01:20 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Kyle Hamilton" References: <20070115154600.A77285C01E@laser.networkresonance.com> <86ac0ke02o.fsf@raman.networkresonance.com> <6b9359640701151745h711a1701xb0612dfc280e509@mail.gmail.com> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session Date: Mon, 15 Jan 2007 21:01:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 16 Jan 2007 05:01:22.0602 (UTC) FILETIME=[5DF458A0:01C7392B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Which is why session resumption is an explicitly optional > construct. And, its why the protocol has an explicit no_renegotiation alert; just because the server ASKS for a renegotiate DOES NOT MEAN it gets it. Further, the client can assert user_cancelled, mid handshake and post-ServerHello anyways, even if the full handshake SHOULD proceed. --------- So, lets get down to text:- So, who is for the proposed wording change? If its what EVERYONE understands anyways, adding one clarification term (MUST) to the text quoted by Eric that governs this case ..is evidently going to have zero nay votes (I'll be abstaining). However, two class C students (me and the browser maker cited by Martin) will have been quite properly instructed. Right now, TLS WG is apparently asserting, in effect, that: When attempting to resume a session, a client SHOULD NOT send a no_renegotiate alert if a server proceeds to a full handshake (I.e. populates ServerHello with a non-zero value that is different to that in the ClientHello). Furthermore, the client SHOULD NOT send a user_canceled alert during such a full handshake should the endpoints proceed. Arguably, the WG is asserting the stronger form for both these conditions: MUST. I’ll offer a compromise here, note. IESG could say: if the client seeking session resumption receives a request to proceed with a full handshake , it MUST proceed with the handshake or it MUST immediately send either a no_renegotiation or a user_canceled alert. user_canceled simply means in this context: give me session resumption under the cited ciphersuite, or don’t bother. The server can send a hello-request if it invites the client to retry the sessionid, given it now has knowledge of the "insistence"; otherwise it just closes the TLS connection using the conventions of the bearer. Now, as a principle: Why the SSL application cares to do this is up to the designer of the application. In all cases, as the standard asserts: its never the business of SSL/TLS protocol layer to know or care WHY SSL applications open or close connections, or under what conditions. Its just a state machine that trundles along, doing its automata thing. Whether an SSL application such as https support a usable hypermedia or other web usage experience or not... requires evaluating https and the web client in question. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 16 10:33:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qIp-0000Lz-M3; Tue, 16 Jan 2007 10:32:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qIn-0000L2-SL for tls@ietf.org; Tue, 16 Jan 2007 10:32:45 -0500 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qIc-0001oA-DX for tls@ietf.org; Tue, 16 Jan 2007 10:32:45 -0500 Received: by an-out-0708.google.com with SMTP id d30so607488and for ; Tue, 16 Jan 2007 07:32:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=YfKaO1Fjztzxuu+GGO0T6ffmqvDPKVg3DGHMwyHg4HjNzXnn6emrSjqX8SLveuKpUr9g0rXVnx2k7nb8ms8PgIs54TR2HaNaHFyKYNRbik3NHHq5Yb/VC6riiFMi7mietad9CLqK7zJRcUW5D73oe09Gzxss7fqpL48ItV1EaBg= Received: by 10.64.27.7 with SMTP id a7mr7960906qba.1168961552060; Tue, 16 Jan 2007 07:32:32 -0800 (PST) Received: by 10.65.220.2 with HTTP; Tue, 16 Jan 2007 07:32:31 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 16:32:31 +0100 From: Badra To: tls@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [TLS] Fwd: I-D ACTION:draft-rescorla-tls-extractor-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1381235685==" Errors-To: tls-bounces@lists.ietf.org --===============1381235685== Content-Type: multipart/alternative; boundary="----=_Part_54198_23085300.1168961551612" ------=_Part_54198_23085300.1168961551612 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Jan 15, 2007 9:50 PM Subject: I-D ACTION:draft-rescorla-tls-extractor-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Keying Material Extractors for Transport Layer Security (TLS) Author(s) : E. Rescorla Filename : draft-rescorla-tls-extractor-00.txt Pages : 6 Date : 2007-1-15 A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rescorla-tls-extractor-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rescorla-tls-extractor-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rescorla-tls-extractor-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_Part_54198_23085300.1168961551612 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

---------- Forwarded message ----------
From: Internet-Drafts@ietf.org < Internet-Drafts@ietf.org>
Date: Jan 15, 2007 9:50 PM
Subject: I-D ACTION:draft-rescorla-tls-extractor-00.txt
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title           : Keying Material Extractors for Transport Layer Security (TLS)
       Author(s)       : E. Rescorla
       Filename        : draft-rescorla-tls-extractor-00.txt
       Pages           : 6
       Date            : 2007-1-15

  A number of protocols wish to leverage Transport Layer Security (TLS)
  to perform key establishment but then use some of the keying material
  for their own purposes.  This document describes a general mechanism
  for allowing that.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rescorla-tls-extractor-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-rescorla-tls-extractor-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
       mailserv@ietf.org.
In the body type:
       "FILE /internet-drafts/draft- rescorla-tls-extractor-00.txt".

NOTE:   The mail server at ietf.org can return the document in
       MIME-encoded form by using the "mpack" utility.  To use this
       feature, insert the command "ENCODING mime" before the "FILE"
       command.  To decode the response(s), you will need "munpack" or
       a MIME-compliant mail reader.  Different MIME-compliant mail readers
       exhibit different behavior, especially when dealing with
       "multipart" MIME messages (i.e. documents which have been split
       up into multiple messages), so check your local documentation on
       how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce


------=_Part_54198_23085300.1168961551612-- --===============1381235685== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1381235685==-- From tls-bounces@lists.ietf.org Tue Jan 16 13:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sjT-0006sz-Bx; Tue, 16 Jan 2007 13:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sjS-0006st-4G for tls@ietf.org; Tue, 16 Jan 2007 13:08:26 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sjQ-0002q1-Mj for tls@ietf.org; Tue, 16 Jan 2007 13:08:26 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA22330; Tue, 16 Jan 2007 19:08:16 +0100 (MEZ) From: Martin Rex Message-Id: <200701161808.TAA21231@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session To: home_pw@msn.com Date: Tue, 16 Jan 2007 19:08:15 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 15, 7 09:01:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > So, lets get down to text:- > > So, who is for the proposed wording change? If its what > EVERYONE understands anyways, adding one clarification term > (MUST) to the text quoted by Eric that governs this case > ..is evidently going to have zero nay votes (I'll be > abstaining). However, two class C students (me and the > browser maker cited by Martin) will have been quite properly > instructed. You have to include me in the count of the class C students that appreciate somewhat clearer guidelines in the spec. I think that the TLS spec could elaborate a little more on non-obvious session caching issues. There is, for example the not very obvious session "duplication" that you mentioned, i.e. several servers and several browsers put an established SSL session (right after the SSL handshake has successfully completed) into their session cache and will duplicate the session for parallel connections to the same server (per default many browsers open up to 4 parallel connections to the same target). The SSL sessions on those parallel network connection will normally use the exact same SSL session ID. > > Right now, TLS WG is apparently asserting, in effect, that: > When attempting to resume a session, a client SHOULD NOT > send a no_renegotiate alert if a server proceeds to a full > handshake (I.e. populates ServerHello with a non-zero value > that is different to that in the ClientHello). Furthermore, > the client SHOULD NOT send a user_canceled alert during such > a full handshake should the endpoints proceed. I'm a little confused. A rejected session-resumption differs from a renegotiation. A no_renegotiate alert is not applicable to this situation. Further protected communication is still possible after a denied renegotiation, but it is a fatal error if the server can not or does not want to resume a previous session proposed by the client on a new connection. > > Arguably, the WG is asserting the stronger form for both > these conditions: MUST. > > I’ll offer a compromise here, note. IESG could say: if the > client seeking session resumption receives a request to > proceed with a full handshake , it MUST proceed with the > handshake or it MUST immediately send either a > no_renegotiation or a user_canceled alert. Requiring a server to be able to resume a session is a bad idea. The reasons why a server has deleted a previous SSL session from his cache are manyfold. I recently added a maintenance API to our SSL abstraction layer to flush the SSL session cache mid-flight, e.g. when the server certificate is updated/replaced or the list of trusted CAs is changed. Active sessions remain as they are, but resumption from cache is no longer possible and all new connections will have to go through a full SSL handshake and operate with the new parameters (server cert, trusted CA list). There are various issues that determine how long an SSL session will be considered valid by either side (client and server) and at what point it will be flushed from the cache. The spec says that a session should be valid at most two hours. The SSL session cache management on the server side may flush them much earlier, in particular when the server is under heavy load. HTTP(S)/1.1 keep-alive session also do not live forever. It is to be expected that the server closes them after some idle time, 30 to 60 seconds is not unusual. Clients also commonly close keep-alive sessions after some idle time. Client-side SSL session caching has not been universally implemented. While probably all Web-Browsers have&use it, Apache's mod_proxy seems to entirely lack it. Slicing of Mime-headers so that every line is written as a seperate SSL record is another performance problem created by mod_proxy. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 16 13:31:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t5A-0002c2-VY; Tue, 16 Jan 2007 13:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t59-0002bx-MF for tls@ietf.org; Tue, 16 Jan 2007 13:30:51 -0500 Received: from mail.opera.com ([193.69.113.66] helo=mailbox.opera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6t57-0006Xz-4m for tls@ietf.org; Tue, 16 Jan 2007 13:30:51 -0500 Received: from killashandra-ii.oslo.opera.com (pat.opera.com [193.69.113.22]) by mailbox.opera.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l0GIUk3r021987 for ; Tue, 16 Jan 2007 18:30:46 GMT Date: Tue, 16 Jan 2007 19:28:09 +0100 To: tls@ietf.org From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.02 (Win32) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [TLS] Reminder: I-D ACTION:draft-ietf-tls-interoperability-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yngve@opera.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: , Errors-To: tls-bounces@lists.ietf.org Hello all, There were quite a lot of discussion about some issues presented in this drafts. However, are there other issues that should be investigated in this document? Does anyone have examples of other TLS interoperability problems that have been encountered? On Wed, 18 Oct 2006 21:50:02 +0200, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > Title : Clientside interoperability experiences for the SSL and TLS > protocols > Author(s) : Y. Pettersen > Filename : draft-ietf-tls-interoperability-00.txt > Pages : 30 > Date : 2006-10-18 > > This document presents a number of problems encountered when > implementing TLS 1.0, TLS 1.1 and TLS Extensions for clients, and > their consequences. The problems include servers that refuse to > connect with clients supporting newer versions of the protocol, or > that do not handle such negotiation properly. Another problem > encountered is the incorrect use of values in the protocol messages. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tls-interoperability-00.txt -- 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 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 16 22:53:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H71qL-0007v1-61; Tue, 16 Jan 2007 22:52:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H71qJ-0007uY-SZ for tls@ietf.org; Tue, 16 Jan 2007 22:52:07 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H71qI-0006Kw-GX for tls@ietf.org; Tue, 16 Jan 2007 22:52:07 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0H3q4vt029847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jan 2007 19:52:05 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0H3q3vB013489; Tue, 16 Jan 2007 19:52:04 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 19:52:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Question on Stateless TLS Session Resumption Date: Tue, 16 Jan 2007 19:52:02 -0800 Message-ID: In-Reply-To: <86irfafo3j.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Question on Stateless TLS Session Resumption Thread-Index: Acc3cv+1lLV9zb0ZSx2+3guP6EZJ7ACc8u2A From: "Narayanan, Vidya" To: "EKR" , "Dondeti, Lakshminath" X-OriginalArrivalTime: 17 Jan 2007 03:52:03.0617 (UTC) FILETIME=[D96B5910:01C739EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org =20 > Well, here's what 4507 says: >=20 >=20 > 5.1. Invalidating Sessions >=20 > The TLS specification requires that TLS sessions be=20 > invalidated when > errors occur. [CSSC] discusses the security implications=20 > of this in > detail. In the analysis in this paper, failure to invalidate > sessions does not pose a security risk. This is because the TLS > handshake uses a non-reversible function to derive keys=20 > for a session > so information about one session does not provide an advantage to > attack the master secret or a different session. If a session > invalidation scheme is used, the implementation should verify the > integrity of the ticket before using the contents to invalidate a > session to ensure that an attacker cannot invalidate a chosen > session. >=20 >=20 > [CSSC] is a reference to SBR04, which provides a fairly=20 > detailed analysis of a variety of different ticket revocation schemes. >=20 > -Ekr >=20 I don't believe the above text captures all of what has been discussed in this thread. Let's separate the issues of invalidating sessions and subsequent ticket replays. The above text is referring to the fact that the hash functions used are not reversible and hence, failure to invalidate sessions is not a major problem. That is one aspect. However, as your paper documents, in order to prevent repeated use of invalidated tickets, the server must maintain a "black list" of sessions. The paper refers to this in the context of timing analysis of the master secret, which would involve an attacker different from the client. This also seems true when the client has been revoked priveleges, for instance - if the server invalidated a session because the client must no longer be allowed to access it, the client may continue to replay an unexpired ticket (essentially, the client becomes the attacker here) and without a black list on the server, it is impossible to keep track of that. That does not seem to be captured in the RFC. I think it would have been useful to explicitly state the need for some minimal state at the server in order to thwart these attacks.=20 Vidya _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 17 09:51:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C7Y-0006nN-Uz; Wed, 17 Jan 2007 09:50:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C7Y-0006nI-9a for tls@ietf.org; Wed, 17 Jan 2007 09:50:36 -0500 Received: from bay0-omc1-s35.bay0.hotmail.com ([65.54.246.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7C7T-0006Xh-NA for tls@ietf.org; Wed, 17 Jan 2007 09:50:36 -0500 Received: from hotmail.com ([65.55.131.21]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 17 Jan 2007 06:50:31 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jan 2007 06:50:30 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV11.phx.gbl with DAV; Wed, 17 Jan 2007 14:50:25 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Badra" , References: Subject: Re: [TLS] Fwd: I-D ACTION:draft-rescorla-tls-extractor-00.txt Date: Wed, 17 Jan 2007 06:50:25 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 17 Jan 2007 14:50:30.0848 (UTC) FILETIME=[D5906400:01C73A46] X-Spam-Score: 0.7 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1023053431==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1023053431== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C3_01C73A03.C4089C40" This is a multi-part message in MIME format. ------=_NextPart_000_01C3_01C73A03.C4089C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rescorla-tls-extractor-00.txt I think this is ok, in principle. This was always done. Its been done already, as shown now in the EAP-TLS I-D, for years. This and AEAP suggests a fair amount is being driven from IEEE WGs ( which are closed forums). One should assume a fully finished spec will eventually arrive, much like TLS Evidence, and be presented as a "new workitem" request to IETF, with a quick last call etc. I don't see anything particularly wrong with that, tho. I do believe it does make sense in this era for TLS to a) parameterize the final KDF algorithm (the PRF function itself) b) parameterize the generation of the key block, much as used to be done based on the export flag for the ciphersuite, or the fortezza_dms SSLv3 ciphersuite. As Ive always said - to some ugly barracking from a former IAB member once when discussing SSLVPNs and TLS - SSL transport is not limited to TCP. It is not limited to any notion associated with TCP (half closes, SYN cookies, RR timestamping, 3168 signaling...), tho Ive seen value-added SSL engines that exploit these features. There are lots of (good) uses, in my opinion. and of course the omnipresent abuse potential. Adding the handshake to help with generating keying material for the cores in internet multicast group management is appropriate. Its nice to see this area get worked on, again. (I think this area can do a lot better for voip than the ENUM direction based on DNS resolvers, and really exploit what the IP can REALLY do, when one lets rip.) The work may well interfere with practices already in place for https 80 udp, but they are hardly mainstream. I used to apply the ChangeCipherSpec class of messages (defining my own) to "alter" the copying of keying material from the pending to active state, according to the custom semantics of my scheme. These days, its trivial to define an extension negotiation to agree to that new class of message support, of course. Need to careful of IP issues, here. ------=_NextPart_000_01C3_01C73A03.C4089C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
  A number of protocols wish to leverage Transport Layer = Security=20 (TLS)
  to perform key establishment but then use some of = the=20 keying material
  for their own purposes.  This = document=20 describes a general mechanism
  for allowing = that.


A URL=20 for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rescorla-tls-extractor-= 00.txt

I=20 think this is ok, in principle. This was always done. Its been done = already, as=20 shown now in the EAP-TLS I-D, for years. This and AEAP suggests a fair = amount is=20 being driven from IEEE WGs ( which are closed forums). One should assume = a fully=20 finished spec will eventually arrive, much like TLS Evidence, and be=20 presented  as a "new workitem" request to IETF, with a quick last = call etc.=20 I don=92t see anything particularly wrong with that, tho.
 
I do believe it does make sense in this era for TLS to a) = parameterize the=20 final KDF algorithm (the PRF function itself) b) parameterize the = generation of=20 the key block, much as used to be done based on the export flag for the=20 ciphersuite, or the fortezza_dms SSLv3 ciphersuite. As Ive = always said -=20  to some ugly barracking from a former IAB member once when = discussing=20 SSLVPNs and TLS - SSL transport is not limited to TCP.  It is = not=20 limited to any notion associated with TCP (half closes, SYN cookies, RR=20 timestamping, 3168 signaling...), tho Ive seen value-added = SSL engines that=20 exploit these features.
 
There are lots of (good) uses, in my opinion. and of course the = omnipresent=20 abuse potential. Adding the handshake to help with generating = keying=20 material for the cores in internet multicast group management is=20 appropriate. Its nice to see this area get worked on, again. (I think = this area=20 can do a lot better for voip than the ENUM direction based on DNS = resolvers, and=20 really exploit what the IP can REALLY do, when one lets rip.)
 
The work may well interfere with practices already in place for = https 80=20 udp, but they are hardly mainstream. I used to apply the = ChangeCipherSpec class=20 of messages (defining my own) to "alter" the copying of keying material = from the=20 pending to active state, according to the custom semantics of my scheme. = These=20 days, its trivial to define an extension negotiation to agree to that = new class=20 of message support, of course.
 
Need to careful of IP issues, here.
------=_NextPart_000_01C3_01C73A03.C4089C40-- --===============1023053431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1023053431==-- From tls-bounces@lists.ietf.org Wed Jan 17 14:52:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GoX-0007EY-VM; Wed, 17 Jan 2007 14:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GoW-0007ES-3j for tls@ietf.org; Wed, 17 Jan 2007 14:51:16 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7GoU-0002x7-N9 for tls@ietf.org; Wed, 17 Jan 2007 14:51:16 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA12924 for ; Wed, 17 Jan 2007 20:51:08 +0100 (MEZ) From: Martin Rex Message-Id: <200701171951.UAA11861@uw1048.wdf.sap.corp> Subject: Re: [TLS] when is it ok to resume a cached SSL/TLS session To: tls@ietf.org Date: Wed, 17 Jan 2007 20:51:08 +0100 (MET) In-Reply-To: <200701151435.PAA28213@uw1048.wdf.sap.corp> from "Martin Rex" at Jan 15, 7 03:01:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > > The problem: The popular browser, when trying to access the older > SSL/TLS implementation on a different TCP-Port is sending a > session ID from the newer SSL/TLS implementation, apparently trying > to resume an existing SSL session in the client-side session cache. > > The server doesn't recognize that session and replies with > a Server Hello containing his highest protocol version, plus > plus server certificate message plus client cert request plus > server hello done. The popular Web Browser closes the network > connection without sending any kind of SSL alert and shows > "Page cannot be displayed" to the user. > > > I firmly believe that this is a conceptual flaw on the client > side, making a flawed assumption about when a cached SSL session > can be expected to be resumable. > > The problem is not with the client sending an existing session ID, > it is about dealing with the servers reply during the SSL/TLS handshake. > - a server on a different port might not be sharing the session > cache with the other > - a server on a different port migt be using an entirely different > SSL/TLS protocol implementation supporting different protocol > versions and extensions > - a server on a different port might be using a seperate server cert > - a server on a different port might be sending/using an independent > list of trusted CAs in a client certificate request > > In our customers case, the Browser might be aborting thinking that > the a version rollback attack is being performed, but honestly, I don't > know what the problem is. The browsers SSL implementation is > extremely poor/broken when reporting errors. After some further investigation I have been able to reproduce the error on our machines. It seems to be related to either the ciphersuite or the (algorithm) of the server's certificate (RSA vs DSA). The protocol version doesn't seem to matter in this case. The customer has installed a DSA server certificate on the newer J2EE service and an RSA server certificate on the older C/C++ service. I've just reproduced this behaviour using an IIS with DSA certificate and my own test-server with an RSA certificate on the same host but different ports. When I click an URL referencing the RSA-server on a page served from the DSA-server, the browser aborts with "Page cannot be displayed". When I hit "refresh", the page loads. (Maybe the browser invalidates the client cache entry after the error). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 17 17:48:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JZa-0002hI-F6; Wed, 17 Jan 2007 17:48:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JZX-0002eB-U1 for tls@ietf.org; Wed, 17 Jan 2007 17:47:59 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JZU-0000gE-De for tls@ietf.org; Wed, 17 Jan 2007 17:47:59 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0HMlsfC011183; Wed, 17 Jan 2007 17:47:54 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0HMlrjj008947; Wed, 17 Jan 2007 17:47:53 -0500 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0HMlohS009299; Wed, 17 Jan 2007 17:47:52 -0500 Message-ID: <45AEA795.2080308@redhat.com> Date: Wed, 17 Jan 2007 14:47:49 -0800 From: Wan-Teh Chang User-Agent: Thunderbird 2.0b2pre (Windows/20070117) MIME-Version: 1.0 To: tls mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Here are my review comments on the Internet-Draft "Opaque PRF Inputs for TLS", draft-rescorla-tls-opaque-prf-input-00.txt. 1. The "Introduction" section says that in a number of US Government applications, it is desirable to have some material with four properties. Could you cite the source of these four requirements? Is it NIST Special Publication 800-56A? Is this Internet-Draft related to the "OtherInfo" input to the NIST KDF? Is the material required to be unique or unpredictable? 2. Can you give an example of the opaque PRF input? Without concrete examples, it is hard to assess the usefulness of this Internet-Draft. 3. The title of Section 3 "The OpaquePRFInput Extension" probably should read "The opaque_prf_input Extension." The first sentence in Section 3 probably should read: The opaque PRF input is carried in a new TLS extension called "opaque_prf_input", whose "extension_data" field contains an OpaquePRFInput value. Then, you could remove the last sentence of the first paragraph in Section 3.1. 4. In Section 3.1, the third paragraph explains that the client and server agree on the opaque PRF input based on its length alone. The OpaquePRFInput structure does not have any type information. It seems that the client and server must infer the type of the opaque value by using the length. Since the receiving party may need to decode the opaque value, it seems crucial to know the type of the opaque value, and so it seems that the length alone may not provide adequate type information. I'm just trying to understand the rationale behind the requirement that the lengths of the client and server's opaque PRF inputs be equal. 5. In Section 3.1, the fourth paragraph, the last sentence is: In this case, the server should generate a fatal "handshake_failure" alert. Should the "should" be changed to "SHOULD"? In this case, since the server requires the opaque_prf_input extension, should we say "MUST" instead of "SHOULD"? 6. In Section 3.1, the fifth (last) paragraph, the last sentence is: If a client requires the opaque PRF input feature but the server does not negotiate it, the client SHOULD generate a fatal "handshake_failure" alert. Similar question to the above: since the client requires it, should we say "MUST" instead of "SHOULD"? 7. In Section 3.2, the second paragraph, we have: mixing in the opaque PRF inputs during the MS->keying material conversion would simply involve mixing in the same material twice. I suggest changing "involve mixing" to "mix". 8. In Section 4.1, the last sentence of the first paragraph is hard to understand because of the double negative: there is currently no proof that a larger input space would not make attacks easier. I don't have a better way to say it though. 9. In the References, the last reference (Draft TLS 1.2) is not being used. Wan-Teh Chang _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 17 23:41:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7P4p-000792-7y; Wed, 17 Jan 2007 23:40:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7P4n-00078w-OK for tls@ietf.org; Wed, 17 Jan 2007 23:40:37 -0500 Received: from bay0-omc1-s19.bay0.hotmail.com ([65.54.246.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7P4h-00067X-PM for tls@ietf.org; Wed, 17 Jan 2007 23:40:37 -0500 Received: from hotmail.com ([65.55.131.28]) by bay0-omc1-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 17 Jan 2007 20:40:31 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jan 2007 20:40:31 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV18.phx.gbl with DAV; Thu, 18 Jan 2007 04:40:29 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Wan-Teh Chang" , "tls mailing list" References: <45AEA795.2080308@redhat.com> Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt Date: Wed, 17 Jan 2007 20:40:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 18 Jan 2007 04:40:31.0182 (UTC) FILETIME=[C8E04EE0:01C73ABA] X-Spam-Score: 0.2 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Lets reference RFC4347, and http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-00.txt, and see where some analysis takes us. It cannot be that hard, if Peter can make some sense of it - to build a reasoning context. (1) we should probably link suiteb-00.txt with opaque-prf-input. - SuiteB starts with the core claim that "However, all those cipher suites use SHA-1 as their MAC algorithm, which makes them unsuitable for some applications." Something about SHA-1 means someone can't use them. Perhaps, its because they have to use SHA-256? E.G. http://www.cast-inc.com/cores/sha-256/index.shtml - SuiteB goes on to assert that guess: "A key ingredient of SuiteB not found in RFC4492--or the definition of TLS itself prior to 1.2--is the use of SHA256 or SHA384 for key derivation." And, not only is it disclosing not an issue of MACs (re SHA-1), now it's the KDF. So, there is a ciphersuite issue with MAC *and* KDFs, I'm guessing - SuiteB goes on to define not only some ciphersuites, around the Suite B Algorithms, but also focuses on AEAD-related notions specific to DTLS, probably - which needs such things, being connectionless. It cites and profiles the Galois mode CCM method, defining a nonce form. We should recall that NIST only addressed AES-CCM for 802.11, not wider. It was VERY specifically worded , I recall. I think this is implying that the Galois mode is required, for SuiteB compliance. -Suite B focuses itself a lot on DTLS, links up with its seq_number constructs (that presumably have to worry like TCP seq-nos have to similarly worry), cites RFC3686, and notes that "Because GCM does not use HMAC as a MAC function, the hash function for the TLS PRF must be explicitly specified." - Well, I'm going to guess that draft-rescorla-tls-opaque-prf-input-00.txt is the follow up to the specification need. - SuiteB finishes off with material about EC curves, and how curve selection is being addressed as a function of protocol. (This is quite interesting of itself, note; I have to think about that for a connectioness setting) Ok. I don't see any great mystery or conspiracy going on here (apart from the conspiracy of silence in mailing list discussion by the authors to 3 sets of comments, now, all asserting the same thing, essentially: "Explain & Participate! We cannot be a rubber stamp!" Have the RFC Editor just issue these documents as is, and avoid TLS WG - if it is just too sensitive for USG to be seen arguing over policy stuff, in public standards forums. The RFC Editor has that power, and its not a bad reason to exploit it) Now to (2) lets look at opaque-prf-input. - First we focus on the nonce discussion. So, aha. 28 + 4 = 32. That clears up one mystery for me! Only 28 of the 32 bytes come from a suitable PRNG process fit for nonces; the other 4 are not random, as another part of the TLS spec implied. They are current time. Hmm. Random does not require any particular random properties; Random is just a type name - We can quote now "The client and server each contribute a Random value which is then mixed with secret keying material to produce the final per-association keying material." One should note the use of the term "keying material", associated with the term secret. He didn't say key. He also refers to "keying material" as being the output of the final KDF, having done the classical mix type operation. - Let's contrast now, with fortezza_dms from SSLv3 days. There, they didn't generate keying material for the mac process; it generated mac_secrets (i.e. note the change in doctrinal naming; the former "mac_secret" is now probably goin to be referred to as "keying material", but only in a SuiteB context). This would normally tell you that the mac process has to go through the HSM now, no more soft-mac'ing. For a wired/wireless NIC or layer 3 router doing DTLS, this is not that unusual, where the hard logic of the FPGA cryptocore can handle the overhead of generating the GCM key schedule (using Galois mode math) and doing multiply-expensive SHA-384 mac operations, at high data packet/frame flow rates. - In terms of language usage, it then focuses not on SuitB rationale, but on the actual applications, when asserting: In a number of United States Government applications, it is desirable to have some material with the following properties: 1. It is contributed both by client and server. 2. It is arbitrary-length. 3. It is mixed into the eventual keying material. 4. It is structured and decodable by the receiving party. - It then whine a bit about the current definition of Random, which is "too small" and doesn't have the properties above. Then, it defines the core claim: opaque PRF will address this, basically by having an enhanced Random sent as extensions. - Ok. So mystery over. They cannot fix the Random type definition, so they are passing a better one as an extension. And, its values SHALL have the defined properties, and get used in the final KDF for the SuiteB ciphersuites disclosed in the other document. - There is some confusion in my mind tho. The documents are not really consistent. They also imply that the opaque PRF is also used in the GCM, used to setup the key schedule for the AEAD stream cipher. Some writing clarity is required here. The big picture needs laying out, if TLS WG is to add any IETF value, not available be having the RFC Editor issue it. So, my outstanding issues are: Is the opaque PFR only for the KDF for generating connection state, or is it also for the generating the key schedule? ok. we need to drop the spookiness, and just interact. There is nothing wrong with any of this material in IETF, so long as average joes can read and understand it. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 17 23:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7PEu-00057H-7V; Wed, 17 Jan 2007 23:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7PEs-00057A-Ul for tls@ietf.org; Wed, 17 Jan 2007 23:51:02 -0500 Received: from bay0-omc3-s18.bay0.hotmail.com ([65.54.246.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7PEr-0007hk-Kq for tls@ietf.org; Wed, 17 Jan 2007 23:51:02 -0500 Received: from hotmail.com ([65.55.131.29]) by bay0-omc3-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 17 Jan 2007 20:51:01 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jan 2007 20:51:00 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV19.phx.gbl with DAV; Thu, 18 Jan 2007 04:50:56 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Wan-Teh Chang" , "tls mailing list" References: <45AEA795.2080308@redhat.com> Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt Date: Wed, 17 Jan 2007 20:50:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 18 Jan 2007 04:51:00.0915 (UTC) FILETIME=[4039F030:01C73ABC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Extending the length of the contributed Nonce information in the PRF is nicely disclosed, in section 3.2. What is interesting now is the session resumption disclosure. This may explain why Eric is so adamant that he can FORCE a new handshake, so he can refresh the extensions values for a new TLS Connection? But, as disclosed, its more confusing than before. Now the opaque PRF can only be used in pre-master-secret to master secret generation. In the other document and earlier in the paper, it seemed opaque PRF was being given a rationale for use in final KDF;'s generation of keying material. Between protocol analysis, hacking some extensions to extend the nonce, PRF parameterization, the way it handles session resumption and kind of reverses its rationale... this doesn't look a polished and finished piece of work. is "feels" like work in progress, attempting to apply external policy to standards making. Again, I cannot find any reason not to do this, or be open about it! --------- 3.2. PRF Modifications When the opaque PRF input feature is in use, the opaque PRF input values MUST be mixed into the PRF along with the client and server random values during the PMS->MS conversion. Thus, the PRF becomes: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ClientHello.opaque_prf_input_value + ServerHello.random + ServerHello.opaque_prf_input_value)[0..47]; Because new extensions may not be introduced in resumed handshakes, mixing in the opaque PRF inputs during the MS->keying material conversion would simply involve mixing in the same material twice. Therefore, the opaque PRF inputs are only used when the PMS is converted into the MS. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 00:13:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7PZi-0000nf-IW; Thu, 18 Jan 2007 00:12:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7PZh-0000nJ-1C for tls@ietf.org; Thu, 18 Jan 2007 00:12:33 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7PZf-00023I-Nl for tls@ietf.org; Thu, 18 Jan 2007 00:12:33 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D0C6A1E8C28; Wed, 17 Jan 2007 21:12:24 -0800 (PST) To: Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt References: <45AEA795.2080308@redhat.com> From: Eric Rescorla Date: Wed, 17 Jan 2007 21:12:24 -0800 In-Reply-To: (home pw's message of "Wed, 17 Jan 2007 20:50:54 -0800") Message-ID: <86tzyo6hqf.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > What is interesting now is the session resumption disclosure. This may > explain why Eric is so adamant that he can FORCE a new handshake, so > he can refresh the extensions values for a new TLS Connection? Peter, it's generally polite not to attribute ulterior motives to others. > But, as disclosed, its more confusing than before. Now the opaque PRF > can only be used in pre-master-secret to master secret generation. In > the other document and earlier in the paper, it seemed opaque PRF was > being given a rationale for use in final KDF;'s generation of keying > material. First, I should state that I only have fairly limited insight into the motivation for this extension. I was asked to help design something with a particular set of parameters in the way that would be most tasteful for TLS and that's what I did. I agree it would be nice to have a more explicit rationale for these parameters and I'm working on getting one. That said, not re-mixing the new entropy into the KDF for session key generation wasn't an intentional design feature. It's merely a limitation of the way that session resumption and extensions interact. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 01:10:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7QTI-0000IW-SG; Thu, 18 Jan 2007 01:10:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7QTG-0000IQ-6K for tls@ietf.org; Thu, 18 Jan 2007 01:09:58 -0500 Received: from bay0-omc2-s40.bay0.hotmail.com ([65.54.246.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7QTE-0000eb-Km for tls@ietf.org; Thu, 18 Jan 2007 01:09:58 -0500 Received: from hotmail.com ([65.55.131.30]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 17 Jan 2007 22:09:56 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jan 2007 22:09:56 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV20.phx.gbl with DAV; Thu, 18 Jan 2007 06:09:54 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <45AEA795.2080308@redhat.com> <86tzyo6hqf.fsf@raman.networkresonance.com> Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt Date: Wed, 17 Jan 2007 22:09:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 18 Jan 2007 06:09:56.0005 (UTC) FILETIME=[468F5550:01C73AC7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org ----- Original Message ----- From: "Eric Rescorla" To: Cc: "Wan-Teh Chang" ; "tls mailing list" Sent: Wednesday, January 17, 2007 9:12 PM Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt > writes: >> What is interesting now is the session resumption >> disclosure. This may >> explain why Eric is so adamant that he can FORCE a new >> handshake, so >> he can refresh the extensions values for a new TLS >> Connection? > > Peter, it's generally polite not to attribute ulterior > motives to > others. My apologies. But, I thought it quite an excellent (assumed :-) )rationale, and I am seriously considering its validity; designing protocols is always a tradeoff process. it's a lot better rationale than worrying about deformed error messages in some products. Before I think about mandatory full handshakes on the session resumption case, I think we should first see if we can merge two existing traditions, to do what they need:- (a) let the proposed nonce extension sort out the derivation for the master_secret, part of a sequencing for a normal full handshake; and (b) let an enhanced ChangeCipherSuite message (value "2"?) (use-negotiated as a semantic of the nonce extension) indicate new opaque nonce values for use in the final KDF, in a session resumption case. Put the two together? There is really nothing sacred about ChangeCipherSuite. OK today, it goes on and on about secure state transition, and exists to prove knowledge of the master_secret. But it can also bear two new nonce enhancements to be used "during" said state transition. In my experiments a long time ago, I had them bearing role names strings, to (for purposes similar to TLS Evidence) bind the legal roles of the cliamants to the keying material being "agreed", and the secure state being "now in effect". Imagine the roles names being "client" and "attorney" (versus "client" and "server") Or "buyer and seller", or "licensed realty agent and licensed mortgage broker". Whatever...business protocol is being agreed shall control the transaction. what I did was define 3 states: pending - active - and "superactive". I took the key block resulting from conforming processing upon entering active, hashed it, used it an entropy for a further KDF based on my parameterized ChangeCipherSuite. A bit like fortezza_dms, I then just overwrote the existing keyblock with new values. (Being used in ChangeCipherSuite, it had/has a nice side effect that the nonces/roles are confidential (assuming the ciphersuite is not null-confidentiality). How about proposing something along those lines? I'm now trying to help you, with some brainstorming. > >> But, as disclosed, its more confusing than before. Now >> the opaque PRF >> can only be used in pre-master-secret to master secret >> generation. In >> the other document and earlier in the paper, it seemed >> opaque PRF was >> being given a rationale for use in final KDF;'s >> generation of keying >> material. > > First, I should state that I only have fairly limited > insight into > the motivation for this extension. I was asked to help > design > something with a particular set of parameters in the way > that > would be most tasteful for TLS and that's what I did. I > agree > it would be nice to have a more explicit rationale for > these > parameters and I'm working on getting one. I can already guess. And, I don't thing there is anything strange at all in the basic requiremnets being expressed. Im not sure why your co-author wanted "It is structured and decodable [by the receiving party]." tho. > > That said, not re-mixing the new entropy into the KDF for > session key generation wasn't an intentional design > feature. > It's merely a limitation of the way that session > resumption > and extensions interact. So think beyond extensions; I never used them till recently. Consider now defining a supporting changeCipherSpec message and allow each message to define its secure state definition that go beyond pending and active. This will might remove the angst from the current design - which comes across as being FORCED into a a set of practice that work...but really don't "fit". I think it can "fit fine" tho, if we just think a bit more liberally. Best wishes and good luck. > -Ekr > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 01:34:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7QqO-0005vd-6v; Thu, 18 Jan 2007 01:33:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7QqM-0005sg-Jy for tls@ietf.org; Thu, 18 Jan 2007 01:33:50 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7QqL-0003Cs-LK for tls@ietf.org; Thu, 18 Jan 2007 01:33:50 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id E72AF1E8C28; Wed, 17 Jan 2007 22:33:48 -0800 (PST) To: Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt References: <45AEA795.2080308@redhat.com> From: Eric Rescorla Date: Wed, 17 Jan 2007 22:33:48 -0800 In-Reply-To: (home pw's message of "Wed, 17 Jan 2007 20:40:27 -0800") Message-ID: <86irf44zeb.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Lets reference RFC4347, and > http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-00.txt, > and see where some analysis takes us. It cannot be that hard, if Peter > can make some sense of it - to build a reasoning context. > > (1) we should probably link suiteb-00.txt with opaque-prf-input. Hmm... Well, they were both funded by the same people but they really are separate. This draft is just what it says, a new set of cipher suites profiled to match SuiteB. Note that SuiteB is *algorithms* and is applicable to non-TLS applications such as S/MIME. The SuiteB algorithms have already been published, so the purpose of this document is just to produce cipher suites that match that profile. Note that it also defines some cipher suites that would be good to have. In the rest of this comment I'm going to read where you say "SuiteB" as draft-rescorla-tls-suiteb... > - SuiteB starts with the core claim that "However, all those cipher > suites use SHA-1 as their MAC algorithm, which makes them unsuitable > for some applications." Something about SHA-1 means someone can't use > them. Perhaps, its because they have to use SHA-256? Yes, it's because SuiteB requires SHA-256 or SHA-384. > - SuiteB goes on to assert that guess: "A key ingredient of SuiteB not > found in RFC4492--or the definition of TLS itself prior to 1.2--is the > use of SHA256 or SHA384 for key derivation." And, not only is it > disclosing not an issue of MACs (re SHA-1), now it's the KDF. So, > there is a ciphersuite issue with MAC *and* KDFs, I'm guessing Yes. In general SuiteB is designed to have a set of algorithms of more or less equivalent strength. SHA-1's strength doesn't match the rest of the algorithms. > - SuiteB goes on to define not only some ciphersuites, around the > Suite B Algorithms, but also focuses on AEAD-related notions specific > to DTLS, probably I think you've gone off track here. The rational for GCM isn't that it works with DTLS. There is an interest in GCM in both TLS and DTLS for a bunch of performance reasons. > -Suite B focuses itself a lot on DTLS, links up with its seq_number > constructs (that presumably have to worry like TCP seq-nos have to > similarly worry), Sorry, I think you're off track here again. The reason for using the sequence number as the GCM per-record IV is to make each record independent without having an explicit IV. Note, btw, that in post-San Diego discussion the WG seemed to prefer to have an explicit IV, so I think this sequence number hack is probably going to go away. > cites RFC3686, and notes that "Because GCM does not > use HMAC as a MAC function, the hash function for the TLS PRF must be > explicitly specified." Well, there's nothing mysterious here... GCM doesn't use HMAC and TLS 1.2 requires hashes to use in the KDF, so we have to specify them. > - Well, I'm going to guess that > draft-rescorla-tls-opaque-prf-input-00.txt is the follow up to the > specification need. It's really for an orthogonal purpose. The SuiteB draft is useful even in the absence of that draft. > - SuiteB finishes off with material about EC curves, and how curve > selection is being addressed as a function of protocol. (This is quite > interesting of itself, note; I have to think about that for a > connectioness setting) Well, TLS already supports ECC and SuiteB just requires a specific set of curves, so this section is intended to specify which ones were. > Ok. I don't see any great mystery or conspiracy going on here (apart > from the conspiracy of silence in mailing list discussion by the > authors to 3 sets of comments, now, all asserting the same thing, > essentially: "Explain & Participate! We cannot be a rubber stamp!" > Have the RFC Editor just issue these documents as is, and avoid TLS WG > - > if it is just too sensitive for USG to be seen arguing over policy > stuff, in public standards forums. The RFC Editor has that power, and > its not a bad reason to exploit it) What puzzles you about the design choices in draft-rescorla-tls-suiteb? > - We can quote now "The client and server each contribute a > Random value which is then mixed with secret keying material to > produce the final per-association keying material." One should note > the use of the term "keying material", associated with the term > secret. He didn't say key. He also refers to "keying material" as > being the output of the final KDF, having done the classical mix type > operation. Well, you shouldn't call the DH ZZ a key. It's not. It's a secret. Arguably it's not keying material either... > - It then whine a bit about the current definition of Random, > which is "too small" and doesn't have the properties above. Then, it > defines the core claim: opaque PRF will address this, basically by > having an enhanced Random sent as extensions. > > - Ok. So mystery over. They cannot fix the Random type > definition, so they are passing a better one as an extension. And, its > values SHALL have the defined properties, and get used in the final > KDF for the SuiteB ciphersuites disclosed in the other document. As noted previously, use of the SuiteB cipher suites is orthogonal to use of opaque prf. > - There is some confusion in my mind tho. The documents are not > really consistent. They also imply that the opaque PRF is also used in > the GCM, used to setup the key schedule for the AEAD stream > cipher. I don't see where it implies that and there's no more connection between GCM and the opaque PRF draft than there is between CBC and the opaque PRF draft. > Some writing clarity is required here. The big picture needs > laying out, if TLS WG is to add any IETF value, not available be > having the RFC Editor issue it. So, my outstanding issues are: Is the > opaque PFR only for the KDF for generating connection state, or is it > also for the generating the key schedule? The Opaque PRF is only for generating the master_secret. It is not re-used to generate the keys for the individual algorithms. However, because those keys are generated from the master_secret, entropy from it of course gets fed into the final keys. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 02:02:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RHa-0006D3-GQ; Thu, 18 Jan 2007 02:01:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RHY-0006C4-JR for tls@ietf.org; Thu, 18 Jan 2007 02:01:56 -0500 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7RHV-0006AU-HF for tls@ietf.org; Thu, 18 Jan 2007 02:01:56 -0500 Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0I71lC7018374 for ; Thu, 18 Jan 2007 15:01:47 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JC100L01XZQNV00@mail-apac.sun.com> (original mail from Andrew.Fan@Sun.Com) for tls@ietf.org; Thu, 18 Jan 2007 15:01:47 +0800 (SGT) Received: from [192.168.1.50] ([222.131.111.42]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JC1001AEY6T4NO6@mail-apac.sun.com> for tls@ietf.org; Thu, 18 Jan 2007 15:01:43 +0800 (SGT) Date: Thu, 18 Jan 2007 15:01:40 +0800 From: Andrew Fan To: tls mailing list Message-id: <45AF1B54.7060600@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [TLS] What's the proper alert for sequence wrap. X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi, The RFC4346 says: Sequence numbers are of type uint64 and may not exceed 2^64-1. Sequence numbers do not wrap. If a TLS implementation would need to wrap a sequence number, it must renegotiate instead. In a implementation, if one does not want to support sequence number wrap with renegotiation, a fatal alert should be sent to peer if the sequence number exceed. Or if one side receive a wrapped sequence number, a fatal alert also should be sent to peer. However, I don't find proper alert descriptions for both read and write sequence number exceed cases. Any suggestions? Thanks, Andrew _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 12:40:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7bEC-00010J-S5; Thu, 18 Jan 2007 12:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7bEC-000108-6Z for tls@ietf.org; Thu, 18 Jan 2007 12:39:08 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7bEB-0002RD-02 for tls@ietf.org; Thu, 18 Jan 2007 12:39:08 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 5E000571 for ; Thu, 18 Jan 2007 12:39:26 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 245501CECD for ; Thu, 18 Jan 2007 12:39:25 -0500 (EST) Message-ID: <45AFB096.4030606@pobox.com> Date: Thu, 18 Jan 2007 09:38:30 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls mailing list Subject: Re: [TLS] What's the proper alert for sequence wrap. References: <45AF1B54.7060600@Sun.Com> In-Reply-To: <45AF1B54.7060600@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Practically speaking, you don't ever need to worry about this. Even if you send a billion records every second, it would take 584 years to wrap the sequence number. Mike Andrew Fan wrote: > The RFC4346 says: > > Sequence numbers are of type uint64 and may not > exceed 2^64-1. Sequence numbers do not wrap. If a TLS > implementation would need to wrap a sequence number, it must > renegotiate instead. > > In a implementation, if one does not want to support sequence number > wrap with renegotiation, a fatal alert should be sent to peer if the > sequence number exceed. Or if one side receive a wrapped sequence > number, a fatal alert also should be sent to peer. However, I don't find > proper alert descriptions for both read and write sequence number exceed > cases. > > Any suggestions? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 15:26:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dpK-0004w5-Ef; Thu, 18 Jan 2007 15:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dpJ-0004w0-7t for tls@ietf.org; Thu, 18 Jan 2007 15:25:37 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dpH-0001HA-Vi for tls@ietf.org; Thu, 18 Jan 2007 15:25:37 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0IKPXJe021511; Thu, 18 Jan 2007 15:25:33 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0IKPXsd003019; Thu, 18 Jan 2007 15:25:33 -0500 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0IKPUd1011713; Thu, 18 Jan 2007 15:25:32 -0500 Message-ID: <45AFD7B9.4000402@redhat.com> Date: Thu, 18 Jan 2007 12:25:29 -0800 From: Wan-Teh Chang User-Agent: Thunderbird 2.0b2pre (Windows/20070118) MIME-Version: 1.0 To: tls mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [TLS] Review comments on draft-rescorla-tls-suiteb-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Here are my review comments on the Internet-Draft "SuiteB CipherSuites for TLS", draft-rescorla-tls-suiteb-00.txt. 1. Nit: throughout the document, some of the "SuiteB" probably should be changed to "Suite B", and "CipherSuites" be changed to "Cipher Suites" or "cipher suites". 2. Section 1, the second to last paragraph, "the use of these hash", change "hash" to "hashes" or "hash algorithms". Nit: change "SHA256" to "SHA-256" and "SHA384" to "SHA-384". 3. Section 3, the first paragraph says: ... the function used for key derivation and data integrity be SHA [SHS]. "Fact Sheet NSA Suite B Cryptography" doesn't say anything about key derivation. It only says: Hashing: Secure Hash Algorithm - FIPS 180-2 (using SHA-256 and SHA-384) The second paragraph says: Encryption: Advanced Encryption Standard (AES) - FIPS 197 with keys sizes of 128 and 256 bits) add '(' after "FIPS 197". 4. Section 4. Cipher Suites I'm curious why you didn't define new counter (CTR) mode cipher suites. 5. Section 5, the second paragraph. I'm curious why TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is chosen as the least common denominator. In practice it may be less work to add the new CBC mode cipher suites to existing TLS implementations. 6. Section 5.2, the first paragraph. In the sentence (These are the same curves that appear in FIPS 186-2 and ANSI X9.62 as P256 and P384, respectively). remove "and ANSI X9.62", change "P256" to "P-256" and "P384" to "P-384", and change ")." to ".)". ANSI X9.62 calls these curves ansix9p256r1 and ansix9p384r1. In the sentence For cipher suites at the 192-bit security level, secp256r MUST be used. change "secp256r" to "secp384r1". The last sentence says Both uncompressed (0) and ansiX962_compressed_prime(1) point formats SHOULD be supported. Are you sure that ansiX962_compressed_prime(1) point format "SHOULD" be supported? RFC 4492 Section 5.1.2 only uses "MAY". 6. Section 5.2, the last paragraph. The last sentence says Clients SHOULD check the chosen curve to make sure it is acceptable. It seems that we should use "MUST" here. 7. Section 7.2. Perfect Forward Secrecy In the last sentence, I suggest changing "mode of operation" to "cipher suite". 8. Section 7.3. Counter Reuse with GCM. In "IV construction algorithm", I suggest changing "IV" to "nonce". The GCMNonce is defined in Section 4.2 as follows: struct { case client: uint32 client_write_IV; // low order 32-bits case server: uint32 server_write_IV; // low order 32-bits uint64 seq_num; } GCMNonce. It seems that it's missing "select (...)" around the two cases. 9. Section 10. References. The reference [I-D.ietf-tls-ctr] is not being used. (See my question in comment 4 above about why this I-D doesn't define new CTR mode cipher suites.) Wan-Teh Chang _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 16:10:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eWA-0001Vl-9r; Thu, 18 Jan 2007 16:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eW9-0001Va-Ru for tls@ietf.org; Thu, 18 Jan 2007 16:09:53 -0500 Received: from bay0-omc2-s6.bay0.hotmail.com ([65.54.246.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eW7-00028P-SW for tls@ietf.org; Thu, 18 Jan 2007 16:09:53 -0500 Received: from hotmail.com ([65.55.131.24]) by bay0-omc2-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 18 Jan 2007 13:09:51 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jan 2007 13:09:51 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV14.phx.gbl with DAV; Thu, 18 Jan 2007 21:09:46 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Mike" , "tls mailing list" References: <45AF1B54.7060600@Sun.Com> <45AFB096.4030606@pobox.com> Subject: Re: [TLS] What's the proper alert for sequence wrap. Date: Thu, 18 Jan 2007 13:09:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 18 Jan 2007 21:09:51.0420 (UTC) FILETIME=[FE55CFC0:01C73B44] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I'm ill with nausea today, and probably thinking less straight than ever. But here goes. --------------- Lets assume we are in a connectionless environment, and the bearer is Not UDP/IP. Its just ethernetv2. Assume we are NOT supported by a connectionless upper layer stack We handshake according to the author's scheme in DTLS, setting up classical duplication detect windows and out of order queues. (NB DTLS REQUIRES us to operate in application space, note, to implement the intent of the designers. Why?... cannot I make a (trusted) socket implementation even if the bearer was UDP?) Lets say, the DTLS sender is a switch working with BPDUs send 2**s packets a second (s) on a ramp, and it now loses 2**s-1 sequence numbers in that same second (s) due to a faulty MAC hardware engine. That is, the switch generates the frame and then just throws it away detecting the mac error in its ASICs, as the speed of at line speed ~10G. Thus, in practice it actually communicates 1 frame a second (with seq_number 2**s-1) on the wire And, the world of hardware being as strange as it is, the receiver now happens to receives seq_number 2*64 (known as 0 in some circles) in the same epoch, and flood of good frames with increasing sequence numbers. Now doesn't the DTLS just recognize 0 as already received, and discard it?h Ok, for commercial systems, I'm assuming unrealistic windows, bit stores, queue length etc. But, if I then receive a frame whose sequence_number I have not previously received, I just accept it don't I? That is, in *this* context it didn't "wrap" did it? -------- This is all interesting tho. There is also the TFTP approach to SSL over UDP with a reasonable reliability mechanism from tftp itself, and the EAP-TLS with its built in fragmentation/retry process, including now the record_layer (as EAP-TLS now has its privacy mode for sending user id to the radius server). I'm not sure why DTLS has such a grudge against RC4. , ----- Original Message ----- From: "Mike" To: "tls mailing list" Sent: Thursday, January 18, 2007 9:38 AM Subject: Re: [TLS] What's the proper alert for sequence wrap. > Practically speaking, you don't ever need to worry about > this. > Even if you send a billion records every second, it would > take > 584 years to wrap the sequence number. > > Mike > > > Andrew Fan wrote: >> The RFC4346 says: >> >> Sequence numbers are of type uint64 and may not >> exceed 2^64-1. Sequence numbers do not wrap. If a >> TLS >> implementation would need to wrap a sequence number, >> it must >> renegotiate instead. >> >> In a implementation, if one does not want to support >> sequence number wrap with renegotiation, a fatal alert >> should be sent to peer if the sequence number exceed. Or >> if one side receive a wrapped sequence number, a fatal >> alert also should be sent to peer. However, I don't find >> proper alert descriptions for both read and write >> sequence number exceed cases. >> >> Any suggestions? > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 16:15:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eau-0000FM-Jd; Thu, 18 Jan 2007 16:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eau-0000D0-2i for tls@ietf.org; Thu, 18 Jan 2007 16:14:48 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eas-00034f-NM for tls@ietf.org; Thu, 18 Jan 2007 16:14:48 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BF25D1E8C28; Thu, 18 Jan 2007 13:14:45 -0800 (PST) To: Subject: Re: [TLS] What's the proper alert for sequence wrap. References: <45AF1B54.7060600@Sun.Com> <45AFB096.4030606@pobox.com> From: Eric Rescorla Date: Thu, 18 Jan 2007 13:14:45 -0800 In-Reply-To: (home pw's message of "Thu, 18 Jan 2007 13:09:43 -0800") Message-ID: <86irf42g1m.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Lets assume we are in a connectionless environment, and the bearer is > Not UDP/IP. Its just ethernetv2. Assume we are NOT supported by a > connectionless upper layer stack > > We handshake according to the author's scheme in DTLS, setting up > classical duplication detect windows and out of order queues. > > (NB DTLS REQUIRES us to operate in application space, note, to > implement the intent of the designers. Why?... cannot I make a > (trusted) socket implementation even if the bearer was UDP?) There's no reason you can't use DTLS that way. > Lets say, the DTLS sender is a switch working with BPDUs send 2**s > packets a second (s) on a ramp, and it now loses 2**s-1 sequence > numbers in that same second (s) due to a faulty MAC hardware engine. > That is, the switch generates the frame and then just throws it away > detecting the mac error in its ASICs, as the speed of at line speed > ~10G. Thus, in practice it actually communicates 1 frame a second > (with seq_number 2**s-1) on the wire > > And, the world of hardware being as strange as it is, the receiver now > happens to receives seq_number 2*64 (known as 0 in some circles) in > the same epoch, and flood of good frames with increasing sequence > numbers. > > Now doesn't the DTLS just recognize 0 as already received, and discard > it?h > Ok, for commercial systems, I'm assuming unrealistic windows, bit > stores, queue length etc. But, if I then receive a frame whose > sequence_number I have not previously received, I just accept it don't > I? If you assume that DTLS is using an infinite replay window, yes, it treats this as a replay. That's why you can't allow the sequence number to wrap on the sender side, because it creates ambiguity/aliasing. > I'm not sure why DTLS has such a grudge against RC4. Because it's very difficult to make RC4 work properly in an out-of-order delivery mode, which we learned to our distress with WEP. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 18 22:47:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7kiG-0006zA-4L; Thu, 18 Jan 2007 22:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7kiF-0006ys-5o for TLS@lists.ietf.org; Thu, 18 Jan 2007 22:46:47 -0500 Received: from simmts5.bellnexxia.net ([206.47.199.163] helo=simmts5-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7kiD-0000hG-TQ for TLS@lists.ietf.org; Thu, 18 Jan 2007 22:46:47 -0500 Received: from pbo8f8e10aowa ([65.94.166.190]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070119034638.BBQK4412.simmts5-srv.bellnexxia.net@pbo8f8e10aowa> for ; Thu, 18 Jan 2007 22:46:38 -0500 Message-ID: <001c01c73b7c$9c6d9800$bea65e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: Date: Thu, 18 Jan 2007 22:47:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] J2ME and TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi, Can somebody tell me if there is a TLS client for J2ME implementation besides Phaos SSLava Micro? Especially if there are open source projects, etc.? Thanks. -Omirjan _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 19 00:49:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7mbC-0006tI-Ev; Fri, 19 Jan 2007 00:47:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7mbC-0006tD-55 for TLS@lists.ietf.org; Fri, 19 Jan 2007 00:47:38 -0500 Received: from edge.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7mb6-0004BI-Ot for TLS@lists.ietf.org; Fri, 19 Jan 2007 00:47:38 -0500 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JC3005CBPEVM300@dps.sfvic.sunlabs.com> for TLS@lists.ietf.org; Thu, 18 Jan 2007 21:47:19 -0800 (PST) Received: from [10.0.1.2] ([67.174.223.52]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JC3009D5PEUT3X3@mail.sunlabs.com> for TLS@lists.ietf.org; Thu, 18 Jan 2007 21:47:19 -0800 (PST) Date: Thu, 18 Jan 2007 21:47:22 -0800 From: Vipul Gupta Subject: Re: [TLS] J2ME and TLS In-reply-to: <001c01c73b7c$9c6d9800$bea65e41@pbo8f8e10aowa> To: Omirjan Batyrbaev Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 References: <001c01c73b7c$9c6d9800$bea65e41@pbo8f8e10aowa> X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: TLS@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org As part of Sun's open sourcing of Java, the ssl client code in MIDP is now available at: https://phoneme.dev.java.net/source/browse/phoneme/builds/ phoneme_feature-mr1-rc-b04/restricted_crypto/src/ssl/reference/ classes/com/sun/midp/ssl/#dirlist While this code does not implement TLS (only SSL 3.0), the changes required to add TLS functionality aren't very big. Contact me separately if you need help. For a description of the functionality implemented, refer to http://dev.experimentalstuff.com:8082/pubs/COMSOCDec2001gupta.pdf vipul On Jan 18, 2007, at 7:47 PM, Omirjan Batyrbaev wrote: > Hi, > > Can somebody tell me if there is a TLS client for J2ME implementation > besides Phaos SSLava Micro? Especially if there are open source > projects, > etc.? > Thanks. > -Omirjan > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 19 12:25:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xQr-0007mL-AP; Fri, 19 Jan 2007 12:21:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xQp-0007h6-Ct for tls@ietf.org; Fri, 19 Jan 2007 12:21:39 -0500 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7xOD-0006Ic-Je for tls@ietf.org; Fri, 19 Jan 2007 12:18:58 -0500 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.35.480.0) with ESMTP id ; Fri, 19 Jan 2007 09:18:54 -0800 X-Modus-ReverseDNS: OK X-Modus-BlackList: 24.219.24.139=OK;trevp@trevp.net=OK X-Modus-RBL: 24.219.24.139=Excluded X-Modus-Trusted: 24.219.24.139=NO Message-ID: <45B0FED9.1020201@trevp.net> Date: Fri, 19 Jan 2007 09:24:41 -0800 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: Eric Rescorla , Pasi.Eronen@nokia.com, tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [TLS] TLS/SRP WGLC X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, Pasi, all, I believe the LC period for TLS/SRP is up. The discussions were primarily about document status. Aside from the authors, Simon Josefsson and Peter Sylvester spoke in favor of Standard Track. In light of this, are the chairs willing to consider advancing as Proposed Standard, with possibly an additional LC period to allow scrutiny appropriate to a Standards Track document? If not, the authors still hope we can move to Standards Track if/when the time becomes right. We would appreciate any guidance about when it would be appropriate to re-open a discussion about moving the document to Standards Track. Trevor _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 19 12:54:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xw3-0000GV-Tc; Fri, 19 Jan 2007 12:53:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xw2-0000G8-UO for TLS@lists.ietf.org; Fri, 19 Jan 2007 12:53:54 -0500 Received: from bay0-omc1-s33.bay0.hotmail.com ([65.54.246.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7xvg-000438-Sv for TLS@lists.ietf.org; Fri, 19 Jan 2007 12:53:54 -0500 Received: from hotmail.com ([65.55.131.19]) by bay0-omc1-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 19 Jan 2007 09:53:32 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Jan 2007 09:53:31 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV9.phx.gbl with DAV; Fri, 19 Jan 2007 17:53:30 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Vipul Gupta" References: <001c01c73b7c$9c6d9800$bea65e41@pbo8f8e10aowa> Subject: Re: [TLS] J2ME and TLS Date: Fri, 19 Jan 2007 09:53:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 19 Jan 2007 17:53:31.0871 (UTC) FILETIME=[BB9706F0:01C73BF2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: TLS@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Vipul: Given parts of J2ME are in the handsets of many phones, could you give a best estimate of just HOW many installs of SSLv3 your think there might be, globally, in mobile terminals? This would be a fascinating number to approximate. Do these terminals use TCP as the bearer for SSL messages, in general, or otherwise? ----- Original Message ----- From: "Vipul Gupta" To: "Omirjan Batyrbaev" Cc: Sent: Thursday, January 18, 2007 9:47 PM Subject: Re: [TLS] J2ME and TLS > > As part of Sun's open sourcing of Java, the ssl client > code in MIDP is now available at: _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 19 14:39:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zYz-00048P-NX; Fri, 19 Jan 2007 14:38:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zYz-00046F-3J for tls@ietf.org; Fri, 19 Jan 2007 14:38:13 -0500 Received: from edge.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7zYu-0002es-NF for tls@ietf.org; Fri, 19 Jan 2007 14:38:13 -0500 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JC40050WRVCM320@dps.sfvic.sunlabs.com> for tls@ietf.org; Fri, 19 Jan 2007 11:38:00 -0800 (PST) Received: from [129.146.75.114] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JC4009KORVBT3Y3@mail.sunlabs.com> for tls@ietf.org; Fri, 19 Jan 2007 11:38:00 -0800 (PST) Date: Fri, 19 Jan 2007 11:38:04 -0800 From: Vipul Gupta Subject: Re: [TLS] J2ME and TLS In-reply-to: To: home_pw@msn.com Message-id: <85B04BB4-35A1-4232-A40F-FEE84EDFF6D8@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 References: <001c01c73b7c$9c6d9800$bea65e41@pbo8f8e10aowa> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Vipul Gupta , tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I wish I knew but this is a hard number to obtain. While I've seen numbers that say there are nearly a billion cellphones with Java ME worldwide, that doesn't directly translate into SSLv3 installs for at least a couple of reasons: -- HTTPS support only became a requirement for Java ME devices starting with version 2.0 of MIDP (MIDP 1.0 compliance only required HTTP support) -- From what I've heard, many phone set manufacturers treat the reference implementation as just that -- few use it as is, often times their underlying OS has a native SSL/TLS implementation that they reuse under a Java API. I feel reasonably comfortable saying that many phones that support HTTP(S) do not use TCP as the underlying bearer. They just need TCP- like semantics -- in order, loss less delivery. If you are interested in estimating SSLv3 v/s TLSv1 usage, here's an interesting data point. SSL 3.0 ends up being used more often than it should because many deployed servers are "TLS intolerant" due to a bug -- the spec says that the encrypted premaster should carry the highest version proposed by the client but servers with this bug expect the negotiated version instead causing handshake failures. When Mozilla/Firefox encounter such servers they abandon the failed TLS handshake and reconnect using SSL 3.0. I believe this bug was recently fixed by the MS team -- one of the nice outcomes of having engineering teams from various vendors being able to communicate directly with each other as part of the ECC interop forum (http:// dev.experimentalstuff.com:8082). There's also some relevant data at: http://www.securityspace.com/s_survey/sdata/200612/protciph.html vipul On Jan 19, 2007, at 9:53 AM, home_pw@msn.com wrote: > Vipul: > > Given parts of J2ME are in the handsets of many phones, could you > give a best estimate of just HOW many installs of SSLv3 your think > there might be, globally, in mobile terminals? > > This would be a fascinating number to approximate. > > Do these terminals use TCP as the bearer for SSL messages, in > general, or otherwise? > > ----- Original Message ----- > From: "Vipul Gupta" > To: "Omirjan Batyrbaev" > Cc: > Sent: Thursday, January 18, 2007 9:47 PM > Subject: Re: [TLS] J2ME and TLS > >> >> As part of Sun's open sourcing of Java, the ssl client code in >> MIDP is now available at: > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 20 19:08:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8QFF-0005WM-P2; Sat, 20 Jan 2007 19:07:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8QFE-0005Vc-2L for TLS@lists.ietf.org; Sat, 20 Jan 2007 19:07:36 -0500 Received: from simmts7-qfe0.srvr.bell.ca ([206.47.199.165] helo=simmts7-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8QFC-0005FZ-Q9 for TLS@lists.ietf.org; Sat, 20 Jan 2007 19:07:36 -0500 Received: from pbo8f8e10aowa ([65.94.169.126]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070121000730.JEQC25276.simmts7-srv.bellnexxia.net@pbo8f8e10aowa> for ; Sat, 20 Jan 2007 19:07:30 -0500 Message-ID: <003201c73cf0$537172f0$7ea95e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: Date: Sat, 20 Jan 2007 19:08:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [TLS] TLS extension X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi, What is the cleanest (or clean enough) way to extend TLS on server and on the client? I recall reading in some posts about even an RFC to do it. TIA, Omirjan. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 20 19:30:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Qb3-0007LJ-Af; Sat, 20 Jan 2007 19:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Qb1-0007LE-RX for TLS@lists.ietf.org; Sat, 20 Jan 2007 19:30:07 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Qb0-00086S-Lk for TLS@lists.ietf.org; Sat, 20 Jan 2007 19:30:07 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 54243ACC9E for ; Sat, 20 Jan 2007 19:30:22 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 21481ACC9D for ; Sat, 20 Jan 2007 19:30:21 -0500 (EST) Message-ID: <45B2B47A.40907@pobox.com> Date: Sat, 20 Jan 2007 16:31:54 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: TLS@lists.ietf.org Subject: Re: [TLS] TLS extension References: <003201c73cf0$537172f0$7ea95e41@pbo8f8e10aowa> In-Reply-To: <003201c73cf0$537172f0$7ea95e41@pbo8f8e10aowa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > What is the cleanest (or clean enough) way to extend TLS on server and on > the client? I recall reading in some posts about even an RFC to do it. There is an extension mechanism, but you can't use it for private extensions. All extensions must be approved by the IETF since they could compromise the security of TLS. See RFC 4366. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 21 06:14:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8adX-0000Yu-5Q; Sun, 21 Jan 2007 06:13:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8adV-0000Yn-H6 for TLS@lists.ietf.org; Sun, 21 Jan 2007 06:13:21 -0500 Received: from bay0-omc2-s19.bay0.hotmail.com ([65.54.246.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8adP-0006RE-U9 for TLS@lists.ietf.org; Sun, 21 Jan 2007 06:13:21 -0500 Received: from hotmail.com ([65.55.131.23]) by bay0-omc2-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 21 Jan 2007 03:13:15 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Jan 2007 03:13:15 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV13.phx.gbl with DAV; Sun, 21 Jan 2007 11:13:12 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Mike" , References: <003201c73cf0$537172f0$7ea95e41@pbo8f8e10aowa> <45B2B47A.40907@pobox.com> Subject: Re: [TLS] TLS extension Date: Sun, 21 Jan 2007 03:13:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 21 Jan 2007 11:13:15.0236 (UTC) FILETIME=[2562DA40:01C73D4D] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Take this with a pinch of salt, Mike - that IESG must approve your extension. National authorities are NEVER BEHOLDEN to an unrepresentative committee. If they start to get all formal on you, just abuse the OCSP extension. It has its own extensibility model that you can abuse all day. And never forget you can define you own record_type whenever you want. Now, more properly, in terms of commenting on actual documents:- overall extensibility policy for TLS, as issued by IESG, is looking weak. On the one hand you can define your own private messages types, your own private certificate types, private ciphersuites, but you cannot define your own extensions!? When I looked at the flight of the standards, from TLS 1.0 onwards, it all got less precise and controlled from TLS1.0 onwards. TLS1.0 was a VERY tight spec. Then it all went into more typical IETF style with a flurry of updates and rewrites. Now there is a mix of tight and not-tight spec, a mix of editing styles, and some confusing policy signals due to the mix of mandate style(s). Incidentally, I have been looking at WTLS 1.2, for my Bluetooth/voip project. There is a lot IETF could learn from that (monotonic seq_numbers for datagrams, not increasing; use of nullWithNull; multiplexed connections; extensions). The design art is all open (including all the debates about how to handle TCP in a wire/wireless environment). It is just so NOT DOGMATIC; it just takes SSLv3 and updates it for the different KDFs in the TLS-era and then tunes it for the different bearers and upper layer stack process. It just does several jobs, without any pretension. The state machines are excellent addition to the community art, as is the formal model of the protocol spec. If someone has the formal WTLS spec for the modern WAP2.0 spec on a public link, please supply it. I want to see how it evolved further, to merge with TLS extensions, tickets, DTLS etc (assuming that happened). [http://www.wmlclub.com/docs/especwap1.2/SPEC-WTLS-19991105.pdf] ----- Original Message ----- From: "Mike" To: All extensions must be approved by the IETF since > they could compromise the security of TLS. See RFC 4366. > > Mike > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 21 15:01:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ir0-0004FE-NH; Sun, 21 Jan 2007 14:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ir0-0004Ey-5k for TLS@lists.ietf.org; Sun, 21 Jan 2007 14:59:50 -0500 Received: from bay0-omc1-s11.bay0.hotmail.com ([65.54.246.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8iqy-0005RK-C5 for TLS@lists.ietf.org; Sun, 21 Jan 2007 14:59:50 -0500 Received: from hotmail.com ([65.55.131.30]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 21 Jan 2007 11:59:47 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Jan 2007 11:59:47 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV20.phx.gbl with DAV; Sun, 21 Jan 2007 19:59:46 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <003201c73cf0$537172f0$7ea95e41@pbo8f8e10aowa><45B2B47A.40907@pobox.com> Subject: Re: [TLS] TLS extension Date: Sun, 21 Jan 2007 11:59:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 21 Jan 2007 19:59:47.0486 (UTC) FILETIME=[B3D5A3E0:01C73D96] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org This is purely FYI, concerning mostly the client key id extension implications, in WTLS. I've been comparing alert signaling of DTLS with WTLS's analogous datagram mode, of 06 Avril 2001. The alerts that differ between the two seem to be well specified in the WTLS text, but the associated procedures change the semantics of several security critical functions. time_required(11), unknown_key_id(52), disabled_key_id(53), key_exchange_disabled(54), session_not_ready(55), unknown_parameter_index(56), duplicate_finished_received(57), Unlike DTLS which presumably really hinges on TLS (1.2) - which has counter modes and AEAP to allow for (wide-area) routing of the datagrams - I don't see any of this kind of key scheduling apparatus in WAP. At the same time, WAP is essentially about point to point record transfers & gatewaying. We do later see a key_refresh process - a function of seq_number handling (a scheme that presumably assumes small windows, appropriate to P2P links) 1. Clearly, the WTLS keyid are a shared secret regimes, much like WEP of the same era; we have the master_Secret KDF and we have 16 byte nonces in the this and final KDF, of which 14 are random. This 14 byte non-secret nonce is the IV, in some ciphersuites. 1a. Re that SuiteB I-D, in WTLS, there would be no problem with the resume session exchanging new (extended) nonces, for the opaque PRF case. In WAP, one just uses the classical SSLv3-era extended Client/ServerHellos for sharing (extended) nonces values; whereas in TLS doctrine, one must use handshake specific messages per TLS extension negotiation - which don't flow that well under the intended state machine of the session resume case. 2. We also have cleartext alerts (that presumably the network itself can introduce), that an implementation can choose to regard as fatal. One of the cleartext alerts may be time_required, which I'm not sure if it's the network or the wap gateway that produces this. Could we imagine a ICMP packet from a intermediate router influencing the sending DTLS in a similar way?? 3. for key_exchange_disabled (for anonymous modes e.g. self-signed RSA certs), the alert seems to say: don't replace one anonymous grade authentication with another. At the same time, this reduces how much RSA operations one could be performing. Presumably, this is to stop time wasting on the formal rationale, and to perhaps limit RSA repurposing. Lots of anonymous 20 byte rsa exchanges can add up to a decent channel under RSA cryptostrength. 4. Now, All these seem to add up. The semantics of session closing change a little. One can now influence active, current (and duplicated) sessions, with alerts. I not entirely sure I understand what the equivalent regime is for DTLS, concerning fatal's semantics, during (1) active connection security state, versus (2) when pending=active=null "A fatal alert only terminates the session to be created and leaves the existing session intact if the handshaking is conducted on an existing secure session. However, there may be some cases that closing the existing session is desirable. A session_close_notify MUST be sent to the peer if one of the parties decide to terminate the existing session immediately after a fatal alert is sent or received during a handshake that intends to create a new session. Under any other circumstances, a fatal alert is treated normally as described at the beginning of this section." 5. The notion of client key id leads to the PMS, at least for RSA. Thus pre-master secret handling is novel (to me, anyways, for RSA): "This random value is generated by the client. This value appended with the public key is used as the pre-master secret which is used to generate the master secret, as specified in Chapter 11." So, basically, only 20 byes are unknown (unlike 48 in TLS). Why? And the PMS is formally these 20 bytes plus the server's public key value, at the start of the PRF, with a public string, and public nonces. Any ideas what is happening here? Handling 20 bytes cleartext in RSA is the ~same decipherment time as 48 cleartext bytes, under PKCS#1 type 2. Unless there is a datagram explanation here, what's the rationale? 6. we see that the key_refresh function over seq_numbers causes the key_block to be refreshed, changing the symmetric key periodically. And the nonce is used as the IV, in export mode ciphers. 7. we have to remember that WTLS cannot do it own fragmentation, unlike DTLS. Upper layer stacks protocols get to control when keys are changed, therefore in WTLS. by compare and contrast of connectionless TLSs, looking at SuiteB's GCM, the work in AEAP, I think I'm beginning to get a handle on TLS 1.2 era work. > Incidentally, I have been looking at WTLS 1.2, for my > Bluetooth/voip project. There is a lot IETF could learn > from that (monotonic seq_numbers for datagrams, not > increasing; use of nullWithNull; multiplexed connections; > extensions). The design art is all open (including all the > debates about how to handle TCP in a wire/wireless > environment). It is just so NOT DOGMATIC; it just takes > SSLv3 and updates it for the different KDFs in the TLS-era > and then tunes it for the different bearers and upper > layer stack process. It just does several jobs, without > any pretension. The state machines are excellent addition > to the community art, as is the formal model of the > protocol spec. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 21 15:16:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8j6U-0002h8-IV; Sun, 21 Jan 2007 15:15:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8j6T-0002gy-8P for TLS@lists.ietf.org; Sun, 21 Jan 2007 15:15:49 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8j6R-0007tB-I1 for TLS@lists.ietf.org; Sun, 21 Jan 2007 15:15:49 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id A9ECF1E8C28; Sun, 21 Jan 2007 12:15:44 -0800 (PST) To: Subject: Re: [TLS] TLS extension References: <003201c73cf0$537172f0$7ea95e41@pbo8f8e10aowa> <45B2B47A.40907@pobox.com> From: Eric Rescorla Date: Sun, 21 Jan 2007 12:15:44 -0800 In-Reply-To: (home pw's message of "Sun, 21 Jan 2007 11:59:44 -0800") Message-ID: <86bqks16hb.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: TLS@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter, WTLS is not an IETF standard. Discussions of WTLS are not really on-topic for this mailing list. To answer a few points you raise about DTLS. writes: > Unlike DTLS which presumably really hinges on TLS (1.2) - > which has counter modes and AEAP to allow for (wide-area) routing of > the datagrams DTLS does not depend on TLS 1.2 in any way. > 2. We also have cleartext alerts (that presumably the network itself > can introduce), that an implementation can choose to regard as > fatal. One of the cleartext alerts may be time_required, which I'm not > sure if it's the network or the wap gateway that produces this. Could > we imagine a ICMP packet from a intermediate router influencing the > sending DTLS in a similar way?? ICMPs are not handled by DTLS one way or the other. Rather, they are handled by the transport layer and/or the consuming application, as with TLS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 22 15:21:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95e9-00037F-NJ; Mon, 22 Jan 2007 15:20:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95e8-000379-D4 for tls@ietf.org; Mon, 22 Jan 2007 15:20:04 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95e7-0001S7-1o for tls@ietf.org; Mon, 22 Jan 2007 15:20:04 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id CCBC45C01E for ; Mon, 22 Jan 2007 12:27:51 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 22 Jan 2007 12:19:54 -0800 From: Eric Rescorla Message-Id: <20070122202751.CCBC45C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [TLS] Review of draft-santesson-tls-gssapi-00 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org $Id: draft-santesson-tls-gssapi-00-rev.txt,v 1.3 2007/01/22 20:27:34 ekr Exp $ I have reviewed this document and as I indicated in San Diego, I have serious architectural concerns about the way that it interconnects TLS and GSS-API. 1. It's totally unclear what security guarantees TLS is supposed to be getting from GSS. In fact, it's not possible to be clear because there is just some set of mechanism IDs. That may be fine in limited environments but it's not fine in the general case where other extensions might be used with TLS. 2. TLS assumes a fixed number of round trips which is determinable from the resumption state. By contrast, once this draft establishes that GSS is to be used, an arbitrary number of round trips may occur in some way that is invisible to TLS. First, that's a big change to the state machine and second it's architecturally problematic. It's true that there's an indicator in the message for whether it's the last payload or not, but there's no way for the TLS state machine to independently determine whether that has been tampered with. It needs to rely on the GSS state machine. That's problematic both from an engineering and security standpoint. 3. It sets a precedent that the way to interconnect TLS to external security mechanisms is via creating a hole in TLS to carry their mechanisms. This makes TLS more complicated, which is of course the enemy of security protocols. TLS provides a generic mechanism for linking up to externally exchanged keys, courtesy of RFC 4279. All you need to do is arrange for your mechanism to create a PSK-Identity binding on both sides and then you can do an ordinary TLS exchange using TLS PSK. In the WG meeting, I heard concerns from the proponents of this draft that they then needed to arrange a way to carry the GSS handshake and that since their application protocols already had a cutout for TLS they wanted to exploit that cutout. I'm not insensitive to this point, but that doesn't make it architecturally sound. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 23 14:52:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RgL-0003dD-4E; Tue, 23 Jan 2007 14:51:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RgJ-0003d8-W2 for TLS@lists.ietf.org; Tue, 23 Jan 2007 14:51:47 -0500 Received: from bay0-omc3-s34.bay0.hotmail.com ([65.54.246.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9RgH-00056M-KD for TLS@lists.ietf.org; Tue, 23 Jan 2007 14:51:47 -0500 Received: from hotmail.com ([65.55.131.16]) by bay0-omc3-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 23 Jan 2007 11:51:44 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Jan 2007 11:51:44 -0800 Message-ID: Received: from 67.97.95.201 by BAY126-DAV6.phx.gbl with DAV; Tue, 23 Jan 2007 19:51:41 +0000 X-Originating-IP: [67.97.95.201] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Tue, 23 Jan 2007 11:51:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 23 Jan 2007 19:51:44.0923 (UTC) FILETIME=[E907DEB0:01C73F27] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [TLS] proof of receipt service , in RFC 4507; TLS Evidence relationship X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "The server MUST NOT assume that the client actually received the updated ticket until it successfully verifies the client's Finished message." [RFC 4507] I've been modeling out the RFC additions to the state machine, and formulating the security claims a product would make, on asserting compliance. An interesting claim is possible, based on standard's language: Proof of receipt of the content of a ticket, based on the cryptographic properties of the finished messages (and the hashes involved in the finishing process). This proof of receipt is obviously symmetric. There is proof the server received the client's ticket's content(s) too, in the server's finished message. The tickets contents are scheme-defined, of course. It can be a signed XML blob in there! Good. This is what I always wanted. Now, in its own right, the handshake is a proof service for X data (not only the secure state transition). If certificate based ciphersuites are used, it becomes "connection-NR"-grade proof. Like TLS_Evidence asserted, any party can verify stored handshake messages, once the PMS is released to an affadavit/notarized process. The optin, willing acceptance rules governing agreements would seem to be built into the way the ticket extension is negotiated, and the obligations the endpoints have to validate tickets, during reliance and during assertion, per the protocol spec. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 13:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVr4-00024t-19; Fri, 26 Jan 2007 13:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVr2-00024Z-1l for tls@ietf.org; Fri, 26 Jan 2007 13:31:16 -0500 Received: from bay0-omc1-s3.bay0.hotmail.com ([65.54.246.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVqz-0008Vo-AQ for tls@ietf.org; Fri, 26 Jan 2007 13:31:16 -0500 Received: from hotmail.com ([65.55.131.23]) by bay0-omc1-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 26 Jan 2007 10:31:12 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Jan 2007 10:31:12 -0800 Message-ID: Received: from 75.212.179.47 by BAY126-DAV13.phx.gbl with DAV; Fri, 26 Jan 2007 18:31:07 +0000 X-Originating-IP: [75.212.179.47] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Steven M. Bellovin" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Fri, 26 Jan 2007 10:31:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 26 Jan 2007 18:31:12.0288 (UTC) FILETIME=[27CB8A00:01C74178] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I don't see any choice. TLS Evidence has to become a work item. This is not to say I support the particular technical approach: but the initiative is appropriate, addressing with technical means both data retention (corporate wiretapping obligations) and the way in which regulated ESIGN sites are applying https and SSL in practice. ----- Original Message ----- From: To: "Steven M. Bellovin" Cc: "Omirjan Batyrbaev" ; Sent: Thursday, January 11, 2007 12:49 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< >> In any event, your analysis and conclusions are wrong. I've been following up the claim. Specifically, the claim that its all wrong (the implication being its peter bullshit...) And the facts are more interesting that I first thought - mostly because of some new features of IE7 (and vista). I've (re)found two https sites that require custom https-plugins or custom https browsers. Each have (ESIGN-citing) site policies that assert that the plugin/custom-app is the "secure signing device" required by ESIGN. One uses a MSN Money plugin to web-browser (or the MSN Money application), and the other example used a scripted quicktime plugin. Both, plugins interacted with (regulated) financial sites, where specific policies were disclosed concerning "writings". Of course, the whole thrust of ESIGN was to define that records (such as electronic signature (including the digital variety)) can constitute "writings" - despite the 17th Century laws being phrased in old-fashioned media terms (paper, pens, handwriting, etc). The (legal) nature of any writing, ESIGN variants included, continues to demand that they must be reduced to tangible form; that requirement does not go away, for electronic records/signatures. In the case of SSL-based signatures, from custom https plugins (with their assured trust models and CAs etc), that form has to be the server-side audit trail itself - the packets, the TCP fragments, the SSL ciphertext, its cleartext handshakes, or the http data within. TLS Evidence is on the right track, as are other means of exploiting the SSL handshake to preserve (and optionally secure) the "recordation" act. One of the cuter features of the modern IE7 browser, and vista OS, concerns its support for handling the trusted path. One notes from sites that exploit Microsoft own CardSpace (federation) layer 5/6/7 identity technology that certain critical security operations can now CONTROL the UI: presumably to ensure the trust path policy control is in effect. On non-vista reference monitors, IE7 also provides a lower assurance version of the same path property. It allows HTML/javascript to control the webpage UI, specially. Here, something that looks like a "Popup" can be visualized by the browser engine instance, whose own rendering backgrounds the main page post its page-level rendering. This "backgrounding" prevents one from interacting with the details material (in any normal sense). Upon clicking the http(s) button link in the only party of the page that is not-backgrounded, end-user control is resumed - allowing one to interact with the page. This all represent a nice "secure signing device" in its own right, contrasting with earlier generations of plugin-based soft-signing devices. Whether the control release the UI based on the response from the server or not (e.g. a signed xml msg, or a new https sessionid value with a receipt-mac within), is a matter for further investigation. Of course, "secure signing" device is a legal convention, not a technical security claim; it is that which merely satisfies the legal definitions in ESIGN. It embodies what lawyers require when addressing the obligation to ascertain the intent of the parties and their consumer consent, when using electronic signatures in important transactions requiring "writing protocols". I don't see any choice. TLS Evidence has to become a work item. This is not to say I support the particular technical approach: but the initiative is appropriate, addressing with technical means both data retention (corporate wiretapping obligations) and the way in which regulated ESIGN sites are applying https and SSL in practice. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 13:46:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAW5V-0001w6-Eg; Fri, 26 Jan 2007 13:46:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAW5T-0001vR-Jq for tls@ietf.org; Fri, 26 Jan 2007 13:46:11 -0500 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAW5O-0002FA-In for tls@ietf.org; Fri, 26 Jan 2007 13:46:11 -0500 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0QIjrN5009612 for ; Fri, 26 Jan 2007 10:46:02 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCH00C01NO7QN00@d1-sfbay-09.sun.com> (original mail from nelson@bolyard.com) for tls@ietf.org; Fri, 26 Jan 2007 10:45:53 -0800 (PST) Received: from [192.168.0.2] ([67.188.127.211]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCH00MKIO3ZBLZF@d1-sfbay-09.sun.com>; Fri, 26 Jan 2007 10:45:36 -0800 (PST) Date: Fri, 26 Jan 2007 10:45:33 -0800 From: Nelson B Bolyard Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-reply-to: To: Peter Williams Message-id: <45BA4C4D.3070501@bolyard.com> Organization: Spam haters R US MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070123 SeaMonkey/1.5a X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Williams wrote: > I don't see any choice. TLS Evidence has to become a work > item. This is not to say I support the particular technical > approach: but the initiative is appropriate, addressing with > technical means both data retention (corporate wiretapping > obligations) and the way in which regulated ESIGN sites are > applying https and SSL in practice. I still have not heard a convincing case that this stuff belongs in TLS. There doesn't seem to be consensus in the WG that it belongs in TLS, either. So far, the arguments for putting this into TLS seem to be: - we want this to be ubiquitous - TLS is ubiquitous, and TLS already does crypto, so - we should shoe-horn this into TLS. One imagines that the same logic COULD have been used by the SSL/TLS inventors years ago. They could have argued: - we want SSL/TLS to be ubiquitous - TCP is ubiquitous, and already does transport, so - we should shoe-horn TLS into TCP. I'm glad they didn't. The same objections that one might have to putting TLS into TCP apply now, to putting signature-based evidence collection into TLS. -- Nelson B (mozilla TLS implementor) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 16:16:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYPO-0001Zu-Jf; Fri, 26 Jan 2007 16:14:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYPN-0001WG-5Y for tls@ietf.org; Fri, 26 Jan 2007 16:14:53 -0500 Received: from simmts6.bellnexxia.net ([206.47.199.164] helo=simmts6-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYPL-000054-Qr for tls@ietf.org; Fri, 26 Jan 2007 16:14:53 -0500 Received: from pbo8f8e10aowa ([65.94.222.190]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070126211450.SSLV9685.simmts6-srv.bellnexxia.net@pbo8f8e10aowa>; Fri, 26 Jan 2007 16:14:50 -0500 Message-ID: <004101c7418f$301e0130$49af5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "Mike" , "tls mailing list" References: <45AF1B54.7060600@Sun.Com> <45AFB096.4030606@pobox.com> Subject: Re: [TLS] What's the proper alert for sequence wrap. Date: Fri, 26 Jan 2007 16:16:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi, How in practice does a SSL/TLS server assigns the new session IDs? Say, does it increment the older session ID? -Omirjan ----- Original Message ----- From: "Mike" To: "tls mailing list" Sent: Thursday, January 18, 2007 12:38 PM Subject: Re: [TLS] What's the proper alert for sequence wrap. > Practically speaking, you don't ever need to worry about this. > Even if you send a billion records every second, it would take > 584 years to wrap the sequence number. > > Mike > > > Andrew Fan wrote: > > The RFC4346 says: > > > > Sequence numbers are of type uint64 and may not > > exceed 2^64-1. Sequence numbers do not wrap. If a TLS > > implementation would need to wrap a sequence number, it must > > renegotiate instead. > > > > In a implementation, if one does not want to support sequence number > > wrap with renegotiation, a fatal alert should be sent to peer if the > > sequence number exceed. Or if one side receive a wrapped sequence > > number, a fatal alert also should be sent to peer. However, I don't find > > proper alert descriptions for both read and write sequence number exceed > > cases. > > > > Any suggestions? > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 17:17:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZMX-0006TZ-GC; Fri, 26 Jan 2007 17:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZMW-0006TS-NF for tls@ietf.org; Fri, 26 Jan 2007 17:16:00 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZMV-00013I-Gm for tls@ietf.org; Fri, 26 Jan 2007 17:16:00 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id ECEAF2DF for ; Fri, 26 Jan 2007 17:16:20 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id B82C721A7C for ; Fri, 26 Jan 2007 17:16:20 -0500 (EST) Message-ID: <45BA7D9C.1050001@pobox.com> Date: Fri, 26 Jan 2007 14:15:56 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls mailing list Subject: Re: [TLS] What's the proper alert for sequence wrap. References: <45AF1B54.7060600@Sun.Com> <45AFB096.4030606@pobox.com> <004101c7418f$301e0130$49af5e41@pbo8f8e10aowa> In-Reply-To: <004101c7418f$301e0130$49af5e41@pbo8f8e10aowa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > How in practice does a SSL/TLS server assigns the new session IDs? > Say, does it increment the older session ID? In my server the first 32 bits are the UNIX time() and the remaining 28 bytes are random. I include the time to make it easy to expire old sessions. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 20:16:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAc9x-0005eo-Nj; Fri, 26 Jan 2007 20:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAc9w-0005ei-NG for tls@ietf.org; Fri, 26 Jan 2007 20:15:12 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAc9v-0004Pf-Ah for tls@ietf.org; Fri, 26 Jan 2007 20:15:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 7D89934E68; Sat, 27 Jan 2007 14:15:06 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12588-01; Sat, 27 Jan 2007 14:15:06 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 2EB5234E65; Sat, 27 Jan 2007 14:15:05 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 04A6712806D; Sat, 27 Jan 2007 14:15:05 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HAc9s-000363-00; Sat, 27 Jan 2007 14:15:08 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: home_pw@msn.com, nelson@bolyard.com Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <45BA4C4D.3070501@bolyard.com> Message-Id: Date: Sat, 27 Jan 2007 14:15:08 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Nelson B Bolyard writes: >I still have not heard a convincing case that this stuff belongs in TLS. >There doesn't seem to be consensus in the WG that it belongs in TLS, either. I've already pointed this out before, why not make it an Experimental RFC? That's exactly what they're there for. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 21:01:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcrs-0005fk-Pv; Fri, 26 Jan 2007 21:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcrr-0005ff-HL for tls@ietf.org; Fri, 26 Jan 2007 21:00:35 -0500 Received: from simmts7-srv.bellnexxia.net ([206.47.199.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAcrq-0003XH-6r for tls@ietf.org; Fri, 26 Jan 2007 21:00:35 -0500 Received: from pbo8f8e10aowa ([65.94.222.190]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070127020033.ZAYB25276.simmts7-srv.bellnexxia.net@pbo8f8e10aowa>; Fri, 26 Jan 2007 21:00:33 -0500 Message-ID: <006a01c741b7$1969e760$49af5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "Peter Gutmann" , , References: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Fri, 26 Jan 2007 21:01:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org see: ----- Original Message ----- From: "Peter Gutmann" To: ; Cc: Sent: Friday, January 26, 2007 8:15 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > Nelson B Bolyard writes: > > >I still have not heard a convincing case that this stuff belongs in TLS. > >There doesn't seem to be consensus in the WG that it belongs in TLS, either. > > I've already pointed this out before, why not make it an Experimental RFC? > That's exactly what they're there for. Speaking of Experimental RFC - is it allowed to have an Intellectual Property in them (or not to surender any of it to IETF)? And what it takes to be Experimental RFC? -Omirjan > > Peter. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 26 21:23:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdDC-0000Ll-R0; Fri, 26 Jan 2007 21:22:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdD6-0000Dr-4H for tls@ietf.org; Fri, 26 Jan 2007 21:22:32 -0500 Received: from mailhost-dr.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAdBy-00081n-Lu for tls@ietf.org; Fri, 26 Jan 2007 21:21:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id D033E350D5; Sat, 27 Jan 2007 15:21:17 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14846-21; Sat, 27 Jan 2007 15:21:17 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id A324B350D4; Sat, 27 Jan 2007 15:21:17 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 60F0212806D; Sat, 27 Jan 2007 15:21:17 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HAdBx-0004G2-00; Sat, 27 Jan 2007 15:21:21 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: batyr@sympatico.ca, home_pw@msn.com, nelson@bolyard.com, pgut001@cs.auckland.ac.nz Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <006a01c741b7$1969e760$49af5e41@pbo8f8e10aowa> Message-Id: Date: Sat, 27 Jan 2007 15:21:21 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Omirjan Batyrbaev" writes: >And what it takes to be Experimental RFC? See http://www.ietf.org/u/ietfchair/info-exp.html, in particular the Guidelines section which explain the Rules section: # If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208) # If the document contains implicit or explicit success/failure criteria, and it's clear that the outcome can be used as the basis for a recommendation to the IETF community, it's Experimental. Case in point: RFC 1797 "Class A Subnet Experiment" which led to RFC 1879 "Class A Subnet Experiment Results and Recommendations" Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 27 17:20:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAvsK-0005OX-OW; Sat, 27 Jan 2007 17:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAvsJ-0005OS-Av for tls@ietf.org; Sat, 27 Jan 2007 17:18:19 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAvsI-0007Ok-1N for tls@ietf.org; Sat, 27 Jan 2007 17:18:19 -0500 Received: by machshav.com (Postfix, from userid 512) id 74F2BFB47A; Sat, 27 Jan 2007 22:18:13 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CCCD2FB413; Sat, 27 Jan 2007 22:18:12 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 5558676607F; Sat, 27 Jan 2007 17:18:11 -0500 (EST) Date: Sat, 27 Jan 2007 17:18:11 -0500 From: "Steven M. Bellovin" To: "Omirjan Batyrbaev" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <006a01c741b7$1969e760$49af5e41@pbo8f8e10aowa> References: <006a01c741b7$1969e760$49af5e41@pbo8f8e10aowa> Organization: Columbia University X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070127221811.5558676607F@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Fri, 26 Jan 2007 21:01:46 -0500 "Omirjan Batyrbaev" wrote: > Speaking of Experimental RFC - is it allowed to have an Intellectual > Property in them (or not to surender any of it to IETF)? And what it > takes to be Experimental RFC? > You never have to surrender intellectual property to the IETF, and you can include it in an RFC. *But* -- you must disclose any IP interests immediately. See https://datatracker.ietf.org/public/ipr_disclosure.cgi More generally, see RFC 3979 and 3669. (Note: those rules apply to IETF RFCs, whether standards track, Informational, or Experimental. Contact the RFC Editor for rules on indidvidual submissions.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jan 27 23:53:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB20T-0006gI-0o; Sat, 27 Jan 2007 23:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB20S-0006cJ-5I for tls@ietf.org; Sat, 27 Jan 2007 23:51:08 -0500 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB20Q-0004ak-Ku for tls@ietf.org; Sat, 27 Jan 2007 23:51:08 -0500 Received: from hotmail.com ([65.55.131.19]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 27 Jan 2007 20:51:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Jan 2007 20:51:05 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV9.phx.gbl with DAV; Sun, 28 Jan 2007 04:51:00 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Sat, 27 Jan 2007 20:51:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 28 Jan 2007 04:51:05.0509 (UTC) FILETIME=[EB186D50:01C74297] X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org There has been a fair amount of support for experimental, when I look back over the thread. Assuming the authors could live with this, we could proceed, despite some clear and absolute "never-never-never votes". TLS WG could then lead the next generation of the privacy debate - moving privacy beyond black/white strong pairwise encryption claim into being a protocol for asserting "agreed limits for privacy expectations". This would enable SSL to get on with higher value transactions, and move beyond "SSL is great for $1000 e-commerce - that is assured by visa cards anyways". I know in my industry this _is_ being called for, where the transactions are generally 500,000USD or more, and involve a whole slew of regulated activities and licensed parties who required higher assurance from https RECORDS than we have addressed to date. I do think we would have to go back to basics tho. if the work item is accepted - starting with a requirement analysis and call for (competing) protocol designs - designs that can take into account wider understanding of various privacy/data-protection/data-retention regulatory regimes that must be taken into account. And, we must distinguish between TLS Evidence and TLS Authorization. The spec as-is currently is a design that says to me: "create an infrastructure that enforces mandatory data retention in the US, controlling communication capabilities at the router based on testing for "voluntary" optin to that policy regime. If the challenged party rejects the policy optin, deny communications - to show the evidence retention subpoena is being complied with". This apparent ultimate focus of the current concept (TLS Authorization) needs to be separated out of the TLS Evidence. A separate work item should be sought, to justify a place for working on TLS Authorization - a control plane protocol that clearly distinguishes itself from TLS Evidence (a data plane service). By starting with requirements, we would get back to (technical) evidence and its relationship to an enhanced privacy service, addressing such as the role of sessionid cache data retention, the new ticket data retention (and the role of MS key wrapping) and - similarly - ciphertext/cleartext data retention. Several other topics would probably need to get included. If the work item is accepted, this could be some of the underlying work that a section of the working group would need to address and reduce to issue/requirement form., Then, folks can worry about which protocol elements shall represent/control/enforce/store information, at which layer: https-v2/higgins, or TLS1.x. ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; Cc: Sent: Friday, January 26, 2007 6:21 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > "Omirjan Batyrbaev" writes: > >>And what it takes to be Experimental RFC? > > See http://www.ietf.org/u/ietfchair/info-exp.html, in > particular the > Guidelines section which explain the Rules section: > > # If the IETF may publish something based on this on the > standards track once > we know how well this one works, it's Experimental. This > is the typical case > of not being able to decide which protocol is "better" > before we have > experience of dealing with them from a stable > specification. Case in point: > "PGM Reliable Transport Protocol Specification" (RFC > 3208) > > # If the document contains implicit or explicit > success/failure criteria, and > it's clear that the outcome can be used as the basis for > a recommendation to > the IETF community, it's Experimental. Case in point: RFC > 1797 "Class A > Subnet Experiment" which led to RFC 1879 "Class A Subnet > Experiment Results > and Recommendations" > > Peter. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 28 00:03:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB2CB-00039f-Al; Sun, 28 Jan 2007 00:03:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB2C9-00039Z-Gb for tls@ietf.org; Sun, 28 Jan 2007 00:03:13 -0500 Received: from bay0-omc3-s33.bay0.hotmail.com ([65.54.246.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB2C7-0005AI-Vm for tls@ietf.org; Sun, 28 Jan 2007 00:03:13 -0500 Received: from hotmail.com ([65.55.131.13]) by bay0-omc3-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 27 Jan 2007 21:03:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Jan 2007 21:03:11 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV3.phx.gbl with DAV; Sun, 28 Jan 2007 05:03:09 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Sat, 27 Jan 2007 21:03:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 28 Jan 2007 05:03:11.0240 (UTC) FILETIME=[9BAA3080:01C74299] X-Spam-Score: 0.2 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Imagining a TLS Evidence work item to exist, I went a bit further in my ESIGN analysis, contemplating what has changed in the 10 years since I last looked at the issues surrounding SSL's client auth. Its one conception of how TLS Evidence might be approached; its radically different in concept from the design of the protocol in the ID under review. Though different in protocol and assurance claim design, its endgoal is presumably the same as those sought by the authors of the ID. My latest machine happens to have an Infineon TPM chip in the motherboard, that "assists" the IE7/Vista perform the "trusted path" feature of that OS (as described in an earlier missive addressing UI Popups that control interaction with rendered HTML pages). The TPM chip is (amongst other roles) a motherboard-based RSA HSM. The associated windows CSP helps https (in Windows OS) perform the client auth operation in SSL. However, its not the chip nor the client auth evidence that is the "cue" of my interest in all this, concerning TLS evidence management, really. Rather, it's the insertion of the (enhanced) authentication device that ARMS the TPM, that then RSAs the certificateverify message, that matters. And, its not so much the "recording" of this secure arming _event_ that matters, but that said event is part of the well-defined "trusted path" feature of an evaluated trusted OS. If one was to put this the other way around: certs, signatures on SSL messages, storage of PDUs, and even TPM assurance themselves are NOT what really counts in assessing the validity of a signature protocol element conforming to the TLS Evidence spec: it's the insertion of the arming device in the secure signing device that really matters - when you swipe the arming finger on my bio-armed TPM, or insert the smartcard that arms the TPM in other machines. So compared to where we were in 1995, when folks where demoing RSA smartcards signing "client auth" messages in SSLv3 and thereby asserting "NR!", we have moved on in the conceptual understanding of the issues surrounding technical evidence - thanks in part to TPMs role in providing technical evidence to the integrrity protected boot, AND trusted path. For TLS Evidence to constitute a "writing" or a record, we are going to have to combine (1) Assurance of the TPM (or other motherboard-assured peripheral), (2) a trusted path security service from an OS, (3) a "(soft-)signing device", (4) an intent and consumer consent affirmation, (5) an RSA signature on the certificate verify message PLUS (6) "appropriate evidence of the arming" of the TPM. Just because TLS might standardize protocols elements and procedures for a signature record_type on the read and write channels, and link their hashes back to the controlling handshake... this is not enough. We would have to build upon such protocol elements to also address within the layer 7 https-v2 or a higgins/saml/was-federation layer all the related processes that I mentioned above. And the key (pun) may be to move the focus away from magical unicorns of NR and PKI to the practice of showing that "trusted path" assurances were in effect for the stored records - a claim we know how to CC evaluate, even across _networked_ trusted components, these days. ----- Original Message ----- From: To: Cc: Sent: Saturday, January 27, 2007 8:51 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > There has been a fair amount of support for experimental, > when I look back over the thread. Assuming the authors > could live with this, we could proceed, despite some clear > and absolute "never-never-never votes". TLS WG could then > lead the next generation of the privacy debate - moving > privacy beyond black/white strong pairwise encryption > claim into being a protocol for asserting "agreed limits > for privacy expectations". This would enable SSL to get on > with higher value transactions, and move beyond "SSL is > great for $1000 e-commerce - that is assured by visa cards > anyways". I know in my industry this _is_ being called > for, where the transactions are generally 500,000USD or > more, and involve a whole slew of regulated activities and > licensed parties who required higher assurance from https > RECORDS than we have addressed to date. > > I do think we would have to go back to basics tho. if the > work item is accepted - starting with a requirement > analysis and call for (competing) protocol designs - > designs that can take into account wider understanding of > various privacy/data-protection/data-retention regulatory > regimes that must be taken into account. > > And, we must distinguish between TLS Evidence and TLS > Authorization. The spec as-is currently is a design that > says to me: "create an infrastructure that enforces > mandatory data retention in the US, controlling > communication capabilities at the router based on testing > for "voluntary" optin to that policy regime. If the > challenged party rejects the policy optin, deny > communications - to show the evidence retention subpoena > is being complied with". This apparent ultimate focus of > the current concept (TLS Authorization) needs to be > separated out of the TLS Evidence. A separate work item > should be sought, to justify a place for working on TLS > Authorization - a control plane protocol that clearly > distinguishes itself from TLS Evidence (a data plane > service). > > By starting with requirements, we would get back to > (technical) evidence and its relationship to an enhanced > privacy service, addressing such as the role of sessionid > cache data retention, the new ticket data retention (and > the role of MS key wrapping) and - similarly - > ciphertext/cleartext data retention. Several other topics > would probably need to get included. > > If the work item is accepted, this could be some of the > underlying work that a section of the working group would > need to address and reduce to issue/requirement form., > Then, folks can worry about which protocol elements shall > represent/control/enforce/store information, at which > layer: https-v2/higgins, or TLS1.x. > > > ----- Original Message ----- > From: "Peter Gutmann" > To: ; ; > ; > Cc: > Sent: Friday, January 26, 2007 6:21 PM > Subject: Re: [TLS] Please discuss: > draft-housley-evidence-extns-00< > >> "Omirjan Batyrbaev" writes: >> >>>And what it takes to be Experimental RFC? >> >> See http://www.ietf.org/u/ietfchair/info-exp.html, in >> particular the >> Guidelines section which explain the Rules section: >> >> # If the IETF may publish something based on this on the >> standards track once >> we know how well this one works, it's Experimental. This >> is the typical case >> of not being able to decide which protocol is "better" >> before we have >> experience of dealing with them from a stable >> specification. Case in point: >> "PGM Reliable Transport Protocol Specification" (RFC >> 3208) >> >> # If the document contains implicit or explicit >> success/failure criteria, and >> it's clear that the outcome can be used as the basis for >> a recommendation to >> the IETF community, it's Experimental. Case in point: >> RFC 1797 "Class A >> Subnet Experiment" which led to RFC 1879 "Class A Subnet >> Experiment Results >> and Recommendations" >> >> Peter. >> _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 28 02:54:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB4pj-0000Ge-Hq; Sun, 28 Jan 2007 02:52:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB4ph-0000GR-OS for tls@ietf.org; Sun, 28 Jan 2007 02:52:13 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HB4pf-0004NW-4v for tls@ietf.org; Sun, 28 Jan 2007 02:52:13 -0500 Received: (qmail 11134 invoked by uid 0); 28 Jan 2007 07:51:50 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 28 Jan 2007 07:51:50 -0000 Message-Id: <7.0.0.16.2.20070128023901.04a11760@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 28 Jan 2007 02:39:56 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Russ Housley Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: References: <45BA4C4D.3070501@bolyard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter: The TLS IANA rules require a Standards-Track document to allocate the content type number. Russ At 08:15 PM 1/26/2007, Peter Gutmann wrote: >Nelson B Bolyard writes: > > >I still have not heard a convincing case that this stuff belongs in TLS. > >There doesn't seem to be consensus in the WG that it belongs in TLS, either. > >I've already pointed this out before, why not make it an Experimental RFC? >That's exactly what they're there for. > >Peter. > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 28 11:28:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBCrg-0008RN-7T; Sun, 28 Jan 2007 11:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBCrf-0008RI-Mb for tls@ietf.org; Sun, 28 Jan 2007 11:26:47 -0500 Received: from bay0-omc2-s1.bay0.hotmail.com ([65.54.246.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBCre-0007tY-Ag for tls@ietf.org; Sun, 28 Jan 2007 11:26:47 -0500 Received: from hotmail.com ([65.55.131.26]) by bay0-omc2-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 28 Jan 2007 08:26:45 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Jan 2007 08:26:45 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV16.phx.gbl with DAV; Sun, 28 Jan 2007 16:26:44 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Peter Gutmann" , "Russ Housley" References: <45BA4C4D.3070501@bolyard.com> <7.0.0.16.2.20070128023901.04a11760@vigilsec.com> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Sun, 28 Jan 2007 08:26:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 28 Jan 2007 16:26:45.0318 (UTC) FILETIME=[19F5D660:01C742F9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org We need a private range for TLS extensions, then. But, this would require IESG review of an update to a standards track document. Lets not bother with that lio. Or, we introduce immediately introduce an extension with value .next, whose specification says: anyone can use this as a basis for experiment. This Private extension MUST be used with a ciphersuite declared in the private range of ciphersuites. Nothing prevents a private community declaring private ciphersuite X is identical with RSA_RC4_MD5. ----- Original Message ----- From: "Russ Housley" To: "Peter Gutmann" Cc: Sent: Saturday, January 27, 2007 11:39 PM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > Peter: > > The TLS IANA rules require a Standards-Track document to > allocate the content type number. > > Russ > > At 08:15 PM 1/26/2007, Peter Gutmann wrote: >>Nelson B Bolyard writes: >> >> >I still have not heard a convincing case that this stuff >> >belongs in TLS. >> >There doesn't seem to be consensus in the WG that it >> >belongs in TLS, either. >> >>I've already pointed this out before, why not make it an >>Experimental RFC? >>That's exactly what they're there for. >> >>Peter. >> >>_______________________________________________ >>TLS mailing list >>TLS@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 11:02:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYwR-0002F7-1A; Mon, 29 Jan 2007 11:01:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYwP-0002Eu-RU for tls@ietf.org; Mon, 29 Jan 2007 11:01:09 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYwN-0006aC-AC for tls@ietf.org; Mon, 29 Jan 2007 11:01:09 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA21786; Mon, 29 Jan 2007 17:00:59 +0100 (MEZ) From: Martin Rex Message-Id: <200701291558.QAA11833@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: home_pw@msn.com Date: Mon, 29 Jan 2007 16:58:08 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 27, 7 09:03:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > My latest machine happens to have an Infineon TPM chip in > the motherboard, that "assists" the IE7/Vista perform the > "trusted path" feature of that OS (as described in an > earlier missive addressing UI Popups that control > interaction with rendered HTML pages). The TPM chip is > (amongst other roles) a motherboard-based RSA HSM. The > associated windows CSP helps https (in Windows OS) perform > the client auth operation in SSL. The "secure trust path(es)" in Windows (Vista) might be sufficient to apply digital restrictions management to "premium content" but it is insufficient for "digital signatures" replacing traditional end user signatures. For that, you will need a secure trust path between the user(s intent) and the digital signing device, means that it must include the entire visualization device and the user input device(s) which can add to that data pre-signature and which can trigger the signature generation. The visualization device is actually the more important part, because it will provide (application-specific) preformatted data that is to be signed. Keep in mind that the entire visualization device must be trusted, not just the path to it. I've been asking several interesting questions about TLS Evidence that have gone unanswered so far: - applications that receive communication with significant preprocessing by middleware have absolutely no chance to verify now or later whether a received application-level request matches the contents of a signed TLS Evidence blob. Not when receiving it, at never in the future. TLS Evidence applied to a traditional "notary" operation would look like this: A surveillance video camera records you when you enter the building, it records your entire walk to the office, including all details of a potential "pit stop". It records how you fill out the paperwork how you "apply the signature", and how the notary verifies your identity and counter-signs. Then that entire video-tape together with the paperwork is archived, however, it is impossible to verify whether the paperwork that is archived matches the paperwork that is captured on the video-tape. (TLS Evidence equals the video-tape here). There really is no need to secure anything other that the paperwork, the identification and the signing process. The other serious issue with TLS Evidence is its interference with middleware and application design. Think about the "signed HTTP(S) FORM" idea that was mentioned. Somehow the application must tell the TLS stack to start TLS Evidence before sending the Form. How is the app going to identify the communication channel? Actually, it can not. It could guess and "tell" the TLS stack to request TLS Evidence for the SSL session ID through which the FORM was returned. But as we know, an SSL session is not unique, Web Browsers duplicate SSL sessions massively to speed up communication with the Server, and both servers and clients will terminate HTTP/1.1 keep-alive sessions that are idle for some amount of seconds (30-60 seconds is not uncommon) -- so a Form that isn't filled an POSTed within that timeout will be sent on a different communication channel, although it might reuse the same SSL session ID. Basically all the web-shops, online-banking and online-brokerage and ebay do not hold the user responsible for the data entered into the forms for serveral reasons. Instead, some amount of processing is applied to the data and a preformatted page is presented to the user for confirmation. Reasons may be manyfold, like computing a total or checking availability or consistency of an order, but it is also a means to catch some amount of typing (or copy&paste) errors by giving the user a chance to re-think his decision or fix a typo, re-check terms&conditions, re-think warranty or shipping options, what-have-you... For brokerage-style operations, I consider it likely that the decision to by a particular stock how many is determined _before_ either the price/bid and/or the time when to issue, e.g. while watching the ticker. So a signature on the entire communication at the TLS layer might span a significant amount of time and collect large amounts or garbage in between due to how TLS session caching/resumption/duplication is designed to work. I'm wondering whether any one of those who thinks TLS Evidence is useful for applications has ever seen an auditor check a system? They expect to be able to browse through the audit trails and look at (random) samples of their choice, like "show me all audit records for this user during that day between this and that hour" and look at the details. For these auditors, TLS Evidence gobbledigoo blobs will be pretty useless, as they can not programmatically verify whether certain data as processed by the application maps to a particular archived TLS Evidence record. If app-level signed XML was used instead, it will be possible at any time (before processing and during future audits) to verify the signature and check whether the data which the application actually processed really matches the signed audit trail. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 11:21:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZFe-0004Y9-AJ; Mon, 29 Jan 2007 11:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZFd-0004Y2-OR for tls@ietf.org; Mon, 29 Jan 2007 11:21:01 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZFc-0001IG-CH for tls@ietf.org; Mon, 29 Jan 2007 11:21:01 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA10283; Mon, 29 Jan 2007 17:20:44 +0100 (MEZ) From: Martin Rex Message-Id: <200701291620.RAA12250@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: home_pw@msn.com Date: Mon, 29 Jan 2007 17:20:43 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 26, 7 10:31:07 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > I don't see any choice. TLS Evidence has to become a work > item. This is not to say I support the particular technical > approach: but the initiative is appropriate, addressing with > technical means both data retention (corporate wiretapping > obligations) As I previously indicated, according to the Danvers Doctrine, the IETF does not put key-escrow or wire-tapping into its own protocols. Labelling it as "corporate" instead of "national" doesn't make it any better. > > I've (re)found two https sites that require custom > https-plugins or custom https browsers. Each have > (ESIGN-citing) site policies that assert that the > plugin/custom-app is the "secure signing device" required by > ESIGN. One uses a MSN Money plugin to web-browser (or the > MSN Money application), and the other example used a > scripted quicktime plugin. Both, plugins interacted with > (regulated) financial sites, where specific policies were > disclosed concerning "writings". Where is your problem? I think that is an appropriate approach. We have been shipping a frontend signing component with our App frontends for 10 years. TLS Evidence would only be a very small fraction of a solution, and the problems it creates are magnitudes harder than the small fraction of the problem it claims to solve. Providing the plugin(s), even for several different platforms is easy. Builing up a PKI, securely issuing PKI credentials to users and providing a trusted visualization device are the difficult things. TLS Evidence doesn't solve any of that, but adds many serious new problems. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 11:28:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZLh-0005iV-Bd; Mon, 29 Jan 2007 11:27:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZLg-0005iP-6p for tls@ietf.org; Mon, 29 Jan 2007 11:27:16 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZLd-00029E-Eq for tls@ietf.org; Mon, 29 Jan 2007 11:27:16 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id RAA28951; Mon, 29 Jan 2007 17:24:46 +0100 (MEZ) From: Martin Rex Message-Id: <200701291624.RAA12296@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 29 Jan 2007 17:24:46 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Jan 27, 7 02:15:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > > Nelson B Bolyard writes: > > > >I still have not heard a convincing case that this stuff belongs in TLS. > >There doesn't seem to be consensus in the WG that it belongs in TLS, either. > > I've already pointed this out before, why not make it an Experimental RFC? > That's exactly what they're there for. I'm violently opposed to that. TLS Evidence has many problems that are beyond fixing, because of how it is architected and probably because it needs these for its hidden agenda. All suggestions of how to use TLS Evidence in the applications space are so ridiculously lame that I definitely do not want to see TLS Evidence issued as an RFC, not even Informational. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 12:13:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBa3F-0000pZ-9r; Mon, 29 Jan 2007 12:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBa3D-0000pT-9Y for tls@ietf.org; Mon, 29 Jan 2007 12:12:15 -0500 Received: from bay0-omc2-s1.bay0.hotmail.com ([65.54.246.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBa3B-0000hl-U3 for tls@ietf.org; Mon, 29 Jan 2007 12:12:15 -0500 Received: from hotmail.com ([65.55.131.12]) by bay0-omc2-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 29 Jan 2007 09:12:13 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jan 2007 09:12:13 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV2.phx.gbl with DAV; Mon, 29 Jan 2007 17:12:08 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: Date: Mon, 29 Jan 2007 09:12:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Jan 2007 17:12:13.0202 (UTC) FILETIME=[9E51A720:01C743C8] X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: tls@ietf.org Subject: [TLS] private extension Informational I-D X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Another idea, prompted by a private message; informational RFC anyone? Extension 65535 is formally defined; so lets apply it using the conventions of the SSL community when (ab)using the 255 or equivalent value in SSL enum types:- IF a private ciphersuite value is indicated in Server Hello:- (a) TLS extension value 65535 in Client Hello and Server Hello may be interpreted as a PRIVATE extension by TLS endpoints choosing to support one associated PRIVATE client protocols in that private ciphersuite (b) A Private TLS Extension may have an ExtensionValue that should be interpreted as a DER-encoded OID value that MUST not be indicated in another Extension of the same Client/Server hello message (c) the private ciphersuite spec shall specify one or more private client protocol(s) that is/are associated with one or more Private TLS Extensions, including private record_type message(s) NB1 Nothing in the spec of "Extension client_hello_extension_list<0..2^16-1>;" prevents one from having multiple private extension values, distinguished by OID value by convention (b) - which internet-type folks can get by abusing the MIB tree, as usual. NB2 If its necessary to specify the convention that record_type (255) is a private record_type, then such an Informational RFC can do that too. We have the equivalent of the modern MIME regime for extending MIME, then. WE are only tidying up the conventions actually used in the SSL community, by doing this for 65535 and 255 values. The general practice is supported by TLS already, which specified similar conventions (in some areas) ----- Original Message ----- From: To: "Peter Gutmann" ; "Russ Housley" Cc: Sent: Sunday, January 28, 2007 8:26 AM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > > We need a private range for TLS extensions, then. But, > this would require IESG review of an update to a standards > track document. Lets not bother with that lio. > > Or, we introduce immediately introduce an extension with > value .next, whose specification says: anyone can use this > as a basis for experiment. This Private extension MUST be > used with a ciphersuite declared in the private range of > ciphersuites. > > Nothing prevents a private community declaring private > ciphersuite X is identical with RSA_RC4_MD5. > > > ----- Original Message ----- > From: "Russ Housley" > To: "Peter Gutmann" > Cc: > Sent: Saturday, January 27, 2007 11:39 PM > Subject: Re: [TLS] Please discuss: > draft-housley-evidence-extns-00< > >> Peter: >> >> The TLS IANA rules require a Standards-Track document to >> allocate the content type number. >> >> Russ >> >> At 08:15 PM 1/26/2007, Peter Gutmann wrote: >>>Nelson B Bolyard writes: >>> >>> >I still have not heard a convincing case that this >>> >stuff belongs in TLS. >>> >There doesn't seem to be consensus in the WG that it >>> >belongs in TLS, either. >>> >>>I've already pointed this out before, why not make it an >>>Experimental RFC? >>>That's exactly what they're there for. >>> >>>Peter. >>> >>>_______________________________________________ >>>TLS mailing list >>>TLS@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/tls >> >> >> _______________________________________________ >> TLS mailing list >> TLS@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/tls >> _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 13:30:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbFB-0001Ye-Gp; Mon, 29 Jan 2007 13:28:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbF9-0001YS-My for tls@ietf.org; Mon, 29 Jan 2007 13:28:39 -0500 Received: from bay0-omc3-s40.bay0.hotmail.com ([65.54.246.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbF6-0001oz-4C for tls@ietf.org; Mon, 29 Jan 2007 13:28:39 -0500 Received: from hotmail.com ([65.55.131.11]) by bay0-omc3-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 29 Jan 2007 10:28:35 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jan 2007 10:28:35 -0800 Message-ID: Received: from 70.142.20.165 by BAY126-DAV1.phx.gbl with DAV; Mon, 29 Jan 2007 18:28:32 +0000 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <200701291624.RAA12296@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Mon, 29 Jan 2007 10:28:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Jan 2007 18:28:35.0394 (UTC) FILETIME=[4984AA20:01C743D3] X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Sorry Galileo, said the Roman Inquisition: "Experiments must be pre-authorized by those with appropriate wisdom." Heliocentrism, indeed. Ridiculously lame idea. Who knows where that one will lead... censure that thesis, along with all other protesting theses! Never let them even start to "follow the money" [renaissance/watergate] We have to move on. Class C student Peter has his hands on $100 RIP2-capable 802.11i/802.1X gigabit router/switches/bridge/SPIfirewall, doing radius and EAP-TLS over PPPoE, with hardware IPSEC & GRE tunneling support. He and 14 year old Abdul Rahman XXVIth, son of the supermarket owner where they are sold, are both having fun configuring them to work with the TPM EAP-TLS module in their birthday Vista PCs, doing everything that research students were doing 10 years ago to (slowly) get higher assurance out of commodity technology - created mostly by that "evil" DoD hidden agenda: its COTS policy. We cannot stop the experimenting. And should not try. Yes, there are lots of hidden agendas. What's new? They didn't stop us transforming PEM into the full spectrum key management world(s) that SSL now enjoys, did they? Start with grassroot-organized (crappy) security in software, and allow stepup to hardware assurance when some agenda has enough motivate to bother funding it, in some form. In that social process, educate a million users to administer the concepts ... and take charge of privacy issues for themselves, refining the privacy concepts till they are workable - and no longer religious. Quite where it will all lead, we should not worry: a few million well-educated, empowered, well-fed people will sort that out for themselves. Ive been attempting to move the debate away from some well-intentioned, but nontheless dubious protocol design, onto: could we perhaps just address the core 17th centry concepts that one author has indicated are behind the initiative, please: address the undeniable, "evidentiary" value of TLS _records_? One assumes that the hidden agendas of those C17th law makers have worked themselves out by now. Its pointless denying server-side sessionid caches are being raided, by police. Its pointless denying ethereal is used to decrypt stored streams. Its pointless denying that the SSL architecture facilitates such semi-covert practices, that are now mainstream; it has since day 1. What we CAN opt to do is turn it all around, and now do something useful with it (that also regularizes those actual practices, through normal social debate). Now we can lead, or suppress. You get to chose your role, Inquisitor or Galileo, in the role play. To: "Peter Gutmann" Cc: Sent: Monday, January 29, 2007 8:24 AM Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< > I'm violently opposed to that. > > TLS Evidence has many problems that are beyond fixing, > because of > how it is architected and probably because it needs these > for > its hidden agenda. > > All suggestions of how to use TLS Evidence in the > applications space > are so ridiculously lame that I definitely do not want to > see > TLS Evidence issued as an RFC, not even Informational. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 13:59:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbiH-0004I5-G5; Mon, 29 Jan 2007 13:58:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbiG-0004Hv-8G for tls@ietf.org; Mon, 29 Jan 2007 13:58:44 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbiE-0005Pa-Sd for tls@ietf.org; Mon, 29 Jan 2007 13:58:44 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA03855; Mon, 29 Jan 2007 19:58:35 +0100 (MEZ) From: Martin Rex Message-Id: <200701291858.TAA15067@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<< To: home_pw@msn.com Date: Mon, 29 Jan 2007 19:58:35 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 29, 7 10:28:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > We have to move on. Class C student Peter has his hands on > $100 RIP2-capable 802.11i/802.1X gigabit > router/switches/bridge/SPIfirewall, doing radius and EAP-TLS > over PPPoE, with hardware IPSEC & GRE tunneling support. He > and 14 year old Abdul Rahman XXVIth, son of the supermarket > owner where they are sold, are both having fun configuring > them to work with the TPM EAP-TLS module in their birthday > Vista PCs, doing everything that research students were > doing 10 years ago to (slowly) get higher assurance out of > commodity technology - created mostly by that "evil" DoD > hidden agenda: its COTS policy. High assurance at that level is a non-issue for everyone except those secret cellar dwellers. The only purpose that it may serve is either abusive or locking out (free and OpenSource) competition from entire markets. One of the most serious security problems that we have on the internet today is phising and trojaning. TLS Evidence is going to make that only worse. An adequate solution to the Ecommerce stuff would be a standardized application-level information exchange protocol for transfering signature request, signed content and signature verification and trusted / highly assured visualization&signing devices somewhere between a mobile phone and OLTP (i.e. <$50). That is the cheapest and most foolproof approach, and will leave the PC software platform entirely open for development and competition for everyone. The rest of the COTS PCs and software will continue its constand feature creep, and remain bug-ridden and virus&worm plagued for more than a decade. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 15:05:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcjN-0005EL-HJ; Mon, 29 Jan 2007 15:03:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcjM-0005EF-72 for tls@ietf.org; Mon, 29 Jan 2007 15:03:56 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBcjK-0006ak-RS for tls@ietf.org; Mon, 29 Jan 2007 15:03:56 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA10186; Mon, 29 Jan 2007 21:03:47 +0100 (MEZ) From: Martin Rex Message-Id: <200701292003.VAA15960@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: home_pw@msn.com Date: Mon, 29 Jan 2007 21:03:47 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Jan 29, 7 10:28:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org home_pw@msn.com wrote: > > We cannot stop the experimenting. And should not try. Yes, > there are lots of hidden agendas. What's new? They didn't > stop us transforming PEM into the full spectrum key > management world(s) that SSL now enjoys, did they? But that is very far from what really happened. The IETF didn't transform PEM into PKI. SPKI was an IETF approach, but it seemed to have died down (OpenPGP and SSH do their own formats). What happened was, that after the OSI communication protocols had failed miserably in the marketplace, many of the participants of the OSI/ISO standards organization started staffing IETF working groups and with pretty complete Proposals (X.509, SSL, S/Mime) and tried to prevent the IETF from killing further of their existing work as well. A lot of stuff in PKI X.509 is complex bloat and burden, and impairs interoperability for political or business model purposes, and not for its technical merit. One of the cumbersome legacy problems resulting from this approach are the X.500 distinguished names, which are equally unusable for humans and software. The XMLsig guys seemed to have realized that problem too far down the road (stringified distinguished names may be pretty to look at, but close to a dead-end road for futher PKI processing), so the SubjectKeyIdentifiers had to be invented and retrofitted later. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 16:04:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdey-0007Ht-7F; Mon, 29 Jan 2007 16:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdew-0007HK-VG for tls@ietf.org; Mon, 29 Jan 2007 16:03:26 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBdeH-0000b8-GG for tls@ietf.org; Mon, 29 Jan 2007 16:03:26 -0500 Received: (qmail 31029 invoked by uid 0); 29 Jan 2007 20:55:14 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 29 Jan 2007 20:55:14 -0000 Message-Id: <7.0.0.16.2.20070129153305.04acb678@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 29 Jan 2007 15:55:17 -0500 To: martin.rex@sap.com From: Russ Housley Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <200701292003.VAA15960@uw1048.wdf.sap.corp> References: <200701292003.VAA15960@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin: >The XMLsig guys seemed to have realized that problem too far down the road >(stringified distinguished names may be pretty to look at, but close to a >dead-end road for futher PKI processing), so the SubjectKeyIdentifiers >had to be invented and retrofitted later. You look at the world differently than me, and that is okay, but I feel a need to correct this historical inaccuracy. Subject key identifiers were added to CMS by me. They were not in PKCS #7 as specified by RSA Labs. They first appeared in draft-ietf-smime-cms-10.txt in December 1998. They were added in recognition that the combination of issuer name and serial number was quite large. This was long before XMLDSIG effort got under way. The -00 draft XML-Signature Requirements document appeared in June 1999. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 17:46:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfFY-0003BW-1e; Mon, 29 Jan 2007 17:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfFW-0003BQ-MD for tls@ietf.org; Mon, 29 Jan 2007 17:45:18 -0500 Received: from bay0-omc3-s13.bay0.hotmail.com ([65.54.246.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfFV-0005b3-9P for tls@ietf.org; Mon, 29 Jan 2007 17:45:18 -0500 Received: from hotmail.com ([65.55.131.15]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 29 Jan 2007 14:45:16 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jan 2007 14:45:16 -0800 Message-ID: Received: from 207.68.174.144 by BAY126-DAV5.phx.gbl with DAV; Mon, 29 Jan 2007 22:45:13 +0000 X-Originating-IP: [207.68.174.144] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: "Peter Williams" Date: Mon, 29 Jan 2007 14:45:13 -0800 thread-index: AcdD9Wn6XKfTUfckQMejO/iMYZI5dw== Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< X-Message-Info: LsUYwwHHNt3660MmjhEvYg2f34OAemlK3oXsmRrh6gU= Received: from smtpde02.sap-ag.de ([155.56.68.170]) by bay0-mc7-f14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Mon, 29 Jan 2007 12:03:53 -0800,from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA10186; Mon, 29 Jan 2007 21:03:47 +0100 (MEZ) Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 In-Reply-To: from "home_pw@msn.com" at Jan 29, 7 10:28:32 am MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-SAP: out X-OriginalArrivalTime: 29 Jan 2007 20:03:53.0953 (UTC) FILETIME=[9A0B8510:01C743E0] X-Spam-Score: 4.2 (++++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org all i can really do to respond to that, apart from arguing too recent = history, is to cite my actual operational choices today. i have about 100 users a second doing federated logon, using saml blob = exchanged between the two endpoint. Today, i sign/verify the saml using = xmldig, as it makes an evidentiary record. I could configure the servers = to use tls to exchange the same saml blob, unsigned. But today i lose = the evidentiary semantics that the xmldig handshake adds to my audit = trail. if i had tls evidence, i could use the tls variant binding, passing the = saml blob in a ticket (peter's solution, today, leveraging existing = stds) or in a tls evidence exchange of some form, tomorrow. -----Original Message----- From: "Martin Rex" Sent: Monday, January 29, 2007 8:03 PM To: "home_pw@msn.com" Cc: "martin.rex@sap.com" , "tls@ietf.org" = Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< home_pw@msn.com wrote: >=20 > We cannot stop the experimenting. And should not try. Yes,=20 > there are lots of hidden agendas. What's new? They didn't=20 > stop us transforming PEM into the full spectrum key=20 > management world(s) that SSL now enjoys, did they? But that is very far from what really happened. The IETF didn't transform PEM into PKI. SPKI was an IETF approach, but it seemed to have died down (OpenPGP and SSH do their own formats). What happened was, that after the OSI communication protocols had failed miserably in the marketplace, many of the participants of the OSI/ISO standards organization started staffing IETF working groups and with pretty complete Proposals (X.509, SSL, S/Mime) and tried to prevent the IETF from killing further of their existing work as well. A lot of stuff in PKI X.509 is complex bloat and burden, and impairs interoperability for political or business model purposes, and not for its technical merit. One of the cumbersome legacy problems resulting from this approach are the X.500 distinguished names, which are equally unusable for humans and software. The XMLsig guys seemed to have realized that problem too far down the = road (stringified distinguished names may be pretty to look at, but close to = a dead-end road for futher PKI processing), so the SubjectKeyIdentifiers had to be invented and retrofitted later. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 17:53:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfN0-0006WE-W6; Mon, 29 Jan 2007 17:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfN0-0006W7-JI for tls@ietf.org; Mon, 29 Jan 2007 17:53:02 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfMz-00074W-2B for tls@ietf.org; Mon, 29 Jan 2007 17:53:02 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0TMr0ZI006202 for ; Mon, 29 Jan 2007 17:53:00 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 29 Jan 2007 17:53:00 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Jan 2007 17:53:00 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Mon, 29 Jan 2007 17:53:00 -0500 Message-ID: In-reply-to: <200701292003.VAA15960@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: AcdD4OmAMWsTj3oCR+q4HeGiPKayxgAAXqMw From: "Kemp, David P." To: X-OriginalArrivalTime: 29 Jan 2007 22:53:00.0657 (UTC) FILETIME=[39F3AE10:01C743F8] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14966000 X-TM-AS-Result: : Yes-0.458100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xMzkw?= =?us-ascii?B?MDYtNzAwMDczLTEzOTAxMC03MDEyOTgtNzA0NzkzLTcwMTYzMi03?= =?us-ascii?B?MDEyOTQtNzAwNjE4LTcwMzM2Ni03MDIzNTgtNzAyMTA2LTcwMTM4?= =?us-ascii?B?Ny03MDIxMzUtNzExODc0LTcwMDY2MS03MDA5MDYtNzA2NDQzLTcw?= =?us-ascii?B?MTkzMy03MDcxODItMTIxMTE5LTcwMDE4NS03MDA1NTEtNzAxNTky?= =?us-ascii?B?LTcwMTg4Ny03MDAyNDMtNzAzMjc4LTcwMTQ1NS03MDM1OTAtNzAx?= =?us-ascii?B?NTg4LTcwOTQxOC03MTEwNzctNzA4MDM5LTcwNjc3NC0xMDY1ODAt?= =?us-ascii?B?NzA0NDQ1LTEwNjY2MC03MDQyNzctNzA1NTI2LTcwMjA3Ni03MDQ0?= =?us-ascii?B?MDctNzAyOTQyLTcwMDUxNi03MDA4MDctNzAzNDY4LTcxMTk4OS03?= =?us-ascii?B?MDg3OTItMTQ4MDUwLTIwMDQy?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com] > The IETF didn't transform PEM into PKI. SPKI was an IETF > approach, but it seemed to have died down (OpenPGP and SSH > do their own formats). Both PEM and S/MIME are email security applications that use an infrastructure, as opposed to local interaction, for key and identity management. Neither PGP keys (in the days of keysigning parties, before keyservers) nor SSH keys qualify as "infrastructure" products generated by public utilities and consumed by the public. SPKI is not an identity-based PKI at all, it is a privilege management scheme that uses keys as principals. The claim that PEM was not the sole IETF predecessor of PKIX (and S/MIME) is based on what sequence of events and RFCs? > What happened was, that after the OSI communication protocols > had failed miserably in the marketplace, many of the participants > of the OSI/ISO standards organization started staffing IETF > working groups and with pretty complete Proposals (X.509, SSL, > S/Mime) and tried to prevent the IETF from killing further of > their existing work as well. The idea that RSA's PKCS-7, on which RSA's trademarked S/MIME was based before being submitted to the IETF, originated with OSI/ISO, is simply bizarre. Same for Netscape's SSL. What planet are you living on?=20 > A lot of stuff in PKI X.509 is complex bloat and burden, > and impairs interoperability for political or business model > purposes, and not for its technical merit. > > One of the cumbersome legacy problems resulting from this > approach are the X.500 distinguished names, which are equally > unusable for humans and software. Do you believe that DNS names, RFC822 names and IP addresses are reasonably usable by humans and software? Do you believe that the X.509 Subject Alternative Name extension is politically-motivated bloat with no technical merit? Certainly X.500 directory names based on a legacy DIT are cumbersome. But the X.509 syntax permits both simple and complex names to be represented as appropriate to the business at hand. It is a failure of imagination among profile authors, not IETF's use of X.509 syntax, that results in difficult distinguished names. An "E" distinguished name, by itself, is perfectly reasonable, as is (for its intended purpose) a DN composed of C's, O's and OU's. Mixing them together creates a truly unpalatable mishmash, but X.509 cannot be blamed for that any more than rope can be blamed for capital punishment. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 19:21:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgjR-0002tD-Mm; Mon, 29 Jan 2007 19:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgjR-0002t3-2W for tls@ietf.org; Mon, 29 Jan 2007 19:20:17 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgjN-0004Bm-4h for tls@ietf.org; Mon, 29 Jan 2007 19:20:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 4CC0C342F9; Tue, 30 Jan 2007 13:20:08 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21508-19; Tue, 30 Jan 2007 13:20:08 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 1C57D340FD; Tue, 30 Jan 2007 13:20:08 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BD2E251400F; Tue, 30 Jan 2007 13:20:07 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HBgjK-000051-00; Tue, 30 Jan 2007 13:20:10 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <200701291624.RAA12296@uw1048.wdf.sap.corp> Message-Id: Date: Tue, 30 Jan 2007 13:20:10 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: >TLS Evidence has many problems that are beyond fixing, because of how it is >architected and probably because it needs these for its hidden agenda. Just for the record I agree that TLS Evidence is Wrong for all the reasons already given, I was just trying to find some middle path. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 29 21:16:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBiWb-0000ye-V6; Mon, 29 Jan 2007 21:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBiWZ-0000xz-Rm for tls@ietf.org; Mon, 29 Jan 2007 21:15:07 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBiWY-0003xk-FI for tls@ietf.org; Mon, 29 Jan 2007 21:15:07 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id DAA06761; Tue, 30 Jan 2007 03:14:59 +0100 (MEZ) From: Martin Rex Message-Id: <200701300214.DAA20860@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< To: housley@vigilsec.com (Russ Housley) Date: Tue, 30 Jan 2007 03:14:57 +0100 (MET) In-Reply-To: <7.0.0.16.2.20070129153305.04acb678@vigilsec.com> from "Russ Housley" at Jan 29, 7 03:55:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > > Martin: > > >The XMLsig guys seemed to have realized that problem too far down the road > >(stringified distinguished names may be pretty to look at, but close to a > >dead-end road for futher PKI processing), so the SubjectKeyIdentifiers > >had to be invented and retrofitted later. > > You look at the world differently than me, and that is okay, but I > feel a need to correct this historical inaccuracy. OK, I'm sorry. Thanks for the clarification. I just happend to read (parts) of the XMLsig spec and the WebServices Security spec, and from one spec to the other, issuer&serial for identifying the signer cert was basically deprecated and subject key identifers were pushed significantly. The problem with distinguished names is that they don't have a canonical encoding, so while a binary issuer&serial still works as a unique database key, the printable ones created by XMLsig don't. > > Subject key identifiers were added to CMS by me. They were not in > PKCS #7 as specified by RSA Labs. They first appeared in > draft-ietf-smime-cms-10.txt in December 1998. They were added in > recognition that the combination of issuer name and serial number was > quite large. Distinguished usually aren't that long. (well, unless stupid CAs are involved that treat the name a digital junkyard and put stuff in there that really doesn't belong there. When one of our customers wanted to get an SSL cert renewed, one particular (susidiary) of a well-know CA choked severely on the name components which it had added...) Admittedly, a fixed short length for a subject key id looks attractive. Unfortunately, they're not unique (re-newed and cross-certs), and when you don't have the cert matching a subject keyid, you don't have the slightest clue where to start looking. Significant added complexity with moderate added value. > > This was long before XMLDSIG effort got under way. The -00 draft > XML-Signature Requirements document appeared in June 1999. The original XMLsig specification seems to prefer Issuer&Serial for identifying the signer cert -- however due to the stringification of the issuer name, lookup of the signer cert becomes somewhat difficult, which might be the reason why WS-Security uses the subject key id (and includes the entire cert). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 30 00:55:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlwH-0007c8-Mi; Tue, 30 Jan 2007 00:53:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlwG-0007bG-9F for tls@ietf.org; Tue, 30 Jan 2007 00:53:52 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBlwD-00024t-2x for tls@ietf.org; Tue, 30 Jan 2007 00:53:52 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id A2632B022E for ; Tue, 30 Jan 2007 00:54:10 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 6E724AEA28 for ; Tue, 30 Jan 2007 00:54:10 -0500 (EST) Message-ID: <45BEDD56.8060101@pobox.com> Date: Mon, 29 Jan 2007 21:53:26 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [TLS] SHA-224, etc. X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Does anyone know of a TLS server that sends a certificate containing a signature using any of the newer SHA algorithms? I just added support for them and want to make sure my code works. Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 30 13:13:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxSH-0001en-OI; Tue, 30 Jan 2007 13:11:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxSG-0001dE-Im for tls@ietf.org; Tue, 30 Jan 2007 13:11:40 -0500 Received: from bay0-omc1-s25.bay0.hotmail.com ([65.54.246.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBxSE-0006KJ-I3 for tls@ietf.org; Tue, 30 Jan 2007 13:11:40 -0500 Received: from BAY126-W3 ([65.55.131.38]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 30 Jan 2007 10:11:38 -0800 Message-ID: X-Originating-IP: [70.142.20.165] From: Peter Williams To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Tue, 30 Jan 2007 10:11:23 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2007 18:11:38.0086 (UTC) FILETIME=[15918860:01C7449A] X-Spam-Score: 2.4 (++) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1546842277==" Errors-To: tls-bounces@lists.ietf.org --===============1546842277== Content-Type: multipart/alternative; boundary="_c542d73d-44bf-44d6-9675-c31419428bbe_" --_c542d73d-44bf-44d6-9675-c31419428bbe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin: The privacy world is changing in the transactional Internet, and we (genera= lly) are not. Just today, in attempting to respond to your own email, my ov= erly-sensitive UA asserted: "You cannot reply to/forward an unopened fraudu= lent message. Please open the message and read it before replying." This is= "Policy-based Control" - in the interests of my security against the servi= ce provider's assumed-Martin-fraud . The UI option to "reply" is only avail= able to me (after two overrides), when my peer can assert that I opened its= envelope first. This is an nice example of the tradeoff between security a= nd control, where control by the service provider over the freedom of the u= ser to choose is a design trend that is evidently in the ascendant (at leas= t in mind of the team designing "Microsoft Windows Live Desktop beta"). I personally find the objection to TLS Evidence experimentation even more t= roubling than the probable intent to subvert the traditional (pairwise) pri= vacy goal of SSL. If the I-D were worded to be upfront about its probably a= rchitectural and social intentions, I'd actually support its evolution more= than I would support the practice of resisting experiment-based discovery.= With clear disclosure, Id remove the "subversion" label, happily. In makin= g that judgment, I'd be supporting the lesser of two evils. After all, corp= orate wiretapping (of SSL) is a totally normal and everyday practice (in th= e USA), whereas limiting Computer Science is generally not. =20 Whilst I don't believe that cryptopolitical devices that hinder experimenta= tion or resist corporate data retention policies will have any actual limit= ing effect upon the evolving practice of SSL in corporate/consumer world, h= ere is my summary of the resolutions asserted in the debate to date:- 1. digital signatures are an appalling abuse-laden idea as custom record_ty= pes, but they are fine if they are an application_record or a handshake mes= sage =20 2. an endpoint's mixing of key exchange keys with seperate signing keys is = an appalling idea, unless its signing a temporary RSA cert with a subjectDN 3. repurposable mechanisms that facilitate corporate wiretapping are contra= ry to the Danvers doctrine, unless one is repurposing the session cache or = tickets for data escrow/retention =20 4. storage of the handshake and application data wiretext/cleartext is unac= ceptable, unless its a loadbalancer's SSL offloading syslog configuration o= r a promiscuous ethereal/IDS forensic trace =20 5. using anti-wiretapping policy arguments against technical measures is no= t itself a violation of the Danvers protocol. So, given one cannot experiment and publish the method in IETF) without con= sensus, and one cannot work on the spec without an agreed workitem, how doe= s now achieve some of the features that folks have identified as possible a= rchitectural benefits:- a. with SSLVPNs at intermediate load balancers offloading decryption and da= ta retention, have end-end signatures represent the interests of the true e= ndpoints =20 b. in DTLS bearing a sipv2 UDP call setup, prior to the RTP connection setu= p, the called party should be able to obtain an affirmative evidentiary sig= nature from the calling party representing "I consent to the call being rec= orded for quality purposes" =20 c. In a transactional stack (e.g. WTLS), TLS-layer signatures can be levera= ged as session-layer tokens, for transaction resumption across (failed) TLS= transport/connections =20 d. Satisfying writings and records standards for higher-value SSL applicati= on subject to intense, anti-fraud regulation =20 --------- =20 If we now roleplay Galileo, and attempt to be too-clever and publish hereti= cal experimental conjectures (in a discourse between imaginary scientists),= let see if I too end up a broken old man humbled through torture into reca= nting. To avoid Galileo's fate, presumably we need to do something that is = only ever conforming:- I. its layer 7. e.g. cert-based =20 II. The protocol element is an existing handshake message, not a custom rec= ord_type =20 III. additional data is transferred in those fields that are under applicat= ion control (vs state machine control) =20 IV. its use does not interfere with connection state =20 V. Adopts https://www.ietf.org X.509 v1 certificate practice, with its OU s= ubject naming practices =20 VI. does not offend the sensibilities of the learned assembly - by saying "= I" rather than "We", hereon after. So, lets presume the liberating force of RSA will be useful, again, and exp= loit it within the confines of the TLS standard. In summary, thus, let's us= e the feature of issuing temporary (signed) RSA certs, in the KEYEXCHANGE s= tate. Then, leverage the ability of either party to abort a re-handshake wi= thout (1) dropping the TLS Connection, (2) affecting the session caches =20 So to get an (authorized) TLS Evidence-style experiment going, with (the he= retical) signatures , I should advance a five msg flow, on an active connec= tion: ClientHello, ServerHello, ClientKeyExchange, Server KeyExchange, non-= fatal-alert. =20 I presumably need to assure folks that this does not de-stabalize current s= essionid caching, as a sessionid is not invalidated by the ServerHello unti= l a finished message is exchanged; something I do not propose doing. I sho= uld offer assurance , furthermore, that the hash values that we take from t= he (locally extended) TLS protocol machine and put in the sessionid value a= re conforming to the TLS standard, in size, syntax and security guidance. I= should give assurance that I will not populate the signed certificate with= any private extension, but use an subject naming field whose (base64-encod= ed) value will take into account the nonces from the latest hellos, the run= ning mac values from the associated read/write connection state, and will o= therwise conform with normal X.509 practice in IETF concerning the OU RDN =20 Now, may I have permission to proceed? I recognize that I'm ending up with = the heretical SSL digital signature in disguise, but I do plead in my favo= ur that I am none the less meeting every rule over (conforming) experiments= identified to date. =20 I would put a final appeal to the learned assembly: that the assumed heresy= is the actual cause of the angst in this debate. Focusing on denying signa= tures in SSL is assuredly going to have no impact upon the adoption of data= retention practices; for these are motivated by socio-political forces, no= t limits imposed on standarization of technology. =20 > From: martin.rex@sap.com> Subject: Re: [TLS] Please discuss: draft-housle= y-evidence-extns-00<> To: housley@vigilsec.com> Date: Tue, 30 Jan 2007 03:1= 4:57 +0100> CC: tls@ietf.org> > Russ Housley wrote:> > > > Martin:> > > > >= The XMLsig guys seemed to have realized that problem too far down the road>= > >(stringified distinguished names may be pretty to look at, but close to= a> > >dead-end road for futher PKI processing), so the SubjectKeyIdentifie= rs> > >had to be invented and retrofitted later.> > > > You look at the wor= ld differently than me, and that is okay, but I > > feel a need to correct = this historical inaccuracy.> > OK, I'm sorry. Thanks for the clarification.= > I just happend to read (parts) of the XMLsig spec and the> WebServices Se= curity spec, and from one spec to the other,> issuer&serial for identifying= the signer cert was basically> deprecated and subject key identifers were = pushed significantly.> > The problem with distinguished names is that they = don't have a> canonical encoding, so while a binary issuer&serial still wor= ks> as a unique database key, the printable ones created by XMLsig> don't.>= > > > > Subject key identifiers were added to CMS by me. They were not in = > > PKCS #7 as specified by RSA Labs. They first appeared in > > draft-ietf= -smime-cms-10.txt in December 1998. They were added in > > recognition that= the combination of issuer name and serial number was > > quite large.> > D= istinguished usually aren't that long.> > (well, unless stupid CAs are invo= lved that treat the name a digital> junkyard and put stuff in there that re= ally doesn't belong there.> When one of our customers wanted to get an SSL = cert renewed,> one particular (susidiary) of a well-know CA choked severely= > on the name components which it had added...)> > Admittedly, a fixed shor= t length for a subject key id looks attractive.> Unfortunately, they're not= unique (re-newed and cross-certs), and> when you don't have the cert match= ing a subject keyid, you don't> have the slightest clue where to start look= ing. Significant> added complexity with moderate added value.> > > > > This= was long before XMLDSIG effort got under way. The -00 draft > > XML-Signat= ure Requirements document appeared in June 1999.> > The original XMLsig spe= cification seems to prefer Issuer&Serial> for identifying the signer cert -= - however due to the stringification> of the issuer name, lookup of the sig= ner cert becomes somewhat difficult,> which might be the reason why WS-Secu= rity uses the subject key id> (and includes the entire cert). > > -Martin> = > _______________________________________________> TLS mailing list> TLS@li= sts.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Live Search: New search found http://get.live.com/search/overview= --_c542d73d-44bf-44d6-9675-c31419428bbe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin:

The privacy world is changing in the transactional Internet, and we (ge= nerally) are not. Just today, in attempting to respond to your own email, m= y overly-sensitive UA asserted: "You cannot reply to/forward an unope= ned fraudulent message. Please open the message and read it before replying= ." This is "Policy-based Control" - in the interests of my security against= the service provider's assumed-Martin-fraud . The UI option to "reply" is = only available to me (after two overrides), when my peer can assert that I = opened its envelope first. This is an nice example of the tradeoff between = security and control, where control by the service provider over the f= reedom of the user to choose is a design trend that is evidently in the asc= endant (at least in mind of the team designing "Microsoft Windows Live Desk= top beta").

I personally find the objection to TLS Evidence experiment= ation even more troubling than the probable intent to subvert the tradition= al (pairwise) privacy goal of SSL. If the I-D were worded to be upfront abo= ut its probably architectural and social intentions, I'd actually support i= ts evolution more than I would support the practice of resisting exper= iment-based discovery. With clear disclosure, Id remove the "subversion" la= bel, happily. In making that judgment, I'd be supporting the lesser of two = evils. After all, corporate wiretapping (of SSL) is a totally normal and ev= eryday practice (in the USA), whereas limiting Computer Science is generall= y not.
 
Whilst I don't believe that cryptopolitical devices that hinder experimenta= tion or resist corporate data retention policies will have any actual limit= ing effect upon the evolving practice of SSL in corporate/consumer world, h= ere is my summary of the resolutions asserted in the debate to date:-<= BR>
1. digital signatures are an appalling abuse-laden idea as custom record_ty= pes, but they are fine if they are an application_record or a handshake mes= sage
 
2. an endpoint's mixing of key exchange keys with seperate signing keys is = an appalling idea, unless its signing a temporary RSA cert with a subjectDN=

3. repurposable mechanisms that facilitate corporate wiretapping are contra= ry to the Danvers doctrine, unless one is repurposing the session cache or = tickets for data escrow/retention
 
4. storage of the handshake and application data wiretext/cleartext is unac= ceptable, unless its a loadbalancer's SSL offloading syslog configurat= ion or a promiscuous ethereal/IDS forensic trace
 
5. using anti-wiretapping policy arguments against technical measures is no= t itself a violation of the Danvers protocol.
So, given one cannot experiment and publish the method in IETF) without con= sensus, and one cannot work on the spec without an agreed workitem, ho= w does now achieve some of the features that folks have identified as possi= ble architectural benefits:-
a. with SSLVPNs at intermediate load balancers offloading decryption and da= ta retention, have end-end signatures represent the interests of the true e= ndpoints
 
b. in DTLS bearing a sipv2 UDP call setup, prior to the RTP connection setu= p, the called party should be able to obtain an affirmative evidentiary&nbs= p;signature from the calling party representing "I consent to the call bein= g recorded for quality purposes"
 
c. In a transactional stack (e.g. WTLS), TLS-layer signatures can be l= everaged as session-layer tokens, for transaction resumption across (failed= ) TLS transport/connections
 
d. Satisfying writings and records standards for higher-value SSL applicati= on subject to intense, anti-fraud regulation
 
---------
 
If we now roleplay Galileo, and attempt to be too-clever and publish hereti= cal experimental conjectures (in a discourse between imaginary scientists),= let see if I too end up a broken old man humbled through torture into reca= nting. To avoid Galileo's fate, presumably we need to do something that is = only ever conforming:-
I. its layer 7. e.g. cert-based
 
II. The protocol element is an existing handshake message, not a custo= m record_type
 
III. additional data is transferred in those fields that are under applicat= ion control (vs state machine control)
 
IV. its use does not interfere with connection state
 
V. Adopts https://www.ietf.org X.509 = v1 certificate practice, with its OU subject naming practices
 
VI. does not offend the sensibilities of the learned assembly - by say= ing "I" rather than "We", hereon after.
So, lets presume the liberating force of RSA will be useful, again, and exp= loit it within the confines of the TLS standard. In summary, thus, let's&nb= sp;use the feature of issuing temporary (signed) RSA certs, in the KEYEXCHA= NGE state. Then, leverage the ability of either party to abort a re-handsha= ke without (1) dropping the TLS Connection, (2) affecting the session cache= s
 
So to get an (authorized) TLS Evidence-style experiment going, with (the he= retical) signatures , I should advance a five msg flow, on an active connec= tion: ClientHello, ServerHello, ClientKeyExchange, Server KeyExchange,= non-fatal-alert.
 
I presumably need to assure folks that this does not de-stabalize current s= essionid caching, as a sessionid is not invalidated by the ServerHello unti= l a finished message is exchanged; something I do not propose doing.  = I should offer assurance , furthermore, that the hash values that we t= ake from the (locally extended) TLS protocol machine and put in the session= id value are conforming to the TLS standard, in size, syntax and security g= uidance. I should give assurance that I will not populate the signed certif= icate with any private extension, but use an subject naming field whose (ba= se64-encoded) value will take into account the nonces from the latest hello= s, the running mac values from the associated read/write connection state, = and will otherwise conform with normal X.509 practice in IETF concerning th= e OU RDN
 
Now, may I have permission to proceed? I recognize that I'm ending up = with the heretical SSL digital signature in disguise, but  I do plead = in my favour that I am none the less meeting every rule over (conforming) e= xperiments identified to date.
 
I would put a final appeal to the learned assembly: that the assumed heresy= is the actual cause of the angst in this debate. Focusing on denying signa= tures in SSL is assuredly going to have no impact upon the adoption of data= retention practices; for these are motivated by socio-political forces, no= t limits imposed on standarization of technology. =20


> From: martin.rex@sap.com
> Subject: Re: [TLS] Please discuss: dr= aft-housley-evidence-extns-00<
> To: housley@vigilsec.com
> = Date: Tue, 30 Jan 2007 03:14:57 +0100
> CC: tls@ietf.org
>
= > Russ Housley wrote:
> >
> > Martin:
> > > > >The XMLsig guys seemed to have realized that problem too fa= r down the road
> > >(stringified distinguished names may be pr= etty to look at, but close to a
> > >dead-end road for futher P= KI processing), so the SubjectKeyIdentifiers
> > >had to be inv= ented and retrofitted later.
> >
> > You look at the wor= ld differently than me, and that is okay, but I
> > feel a need t= o correct this historical inaccuracy.
>
> OK, I'm sorry. Thank= s for the clarification.
> I just happend to read (parts) of the XMLs= ig spec and the
> WebServices Security spec, and from one spec to the= other,
> issuer&serial for identifying the signer cert was basic= ally
> deprecated and subject key identifers were pushed significantl= y.
>
> The problem with distinguished names is that they don't= have a
> canonical encoding, so while a binary issuer&serial sti= ll works
> as a unique database key, the printable ones created by XM= Lsig
> don't.
>
> >
> > Subject key identif= iers were added to CMS by me. They were not in
> > PKCS #7 as spe= cified by RSA Labs. They first appeared in
> > draft-ietf-smime-c= ms-10.txt in December 1998. They were added in
> > recognition th= at the combination of issuer name and serial number was
> > quite= large.
>
> Distinguished usually aren't that long.
> > (well, unless stupid CAs are involved that treat the name a digital<= BR>> junkyard and put stuff in there that really doesn't belong there.> When one of our customers wanted to get an SSL cert renewed,
>= one particular (susidiary) of a well-know CA choked severely
> on th= e name components which it had added...)
>
> Admittedly, a fix= ed short length for a subject key id looks attractive.
> Unfortunatel= y, they're not unique (re-newed and cross-certs), and
> when you don'= t have the cert matching a subject keyid, you don't
> have the slight= est clue where to start looking. Significant
> added complexity with = moderate added value.
>
> >
> > This was long bef= ore XMLDSIG effort got under way. The -00 draft
> > XML-Signature= Requirements document appeared in June 1999.
>
> The original= XMLsig specification seems to prefer Issuer&Serial
> for identif= ying the signer cert -- however due to the stringification
> of the i= ssuer name, lookup of the signer cert becomes somewhat difficult,
> w= hich might be the reason why WS-Security uses the subject key id
> (a= nd includes the entire cert).
>
> -Martin
>
> __= _____________________________________________
> TLS mailing list
&= gt; TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

Get connected - Use your Hotmail address to sign into Win= dows Live Messenger now. Connect now! = --_c542d73d-44bf-44d6-9675-c31419428bbe_-- --===============1546842277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1546842277==-- From tls-bounces@lists.ietf.org Tue Jan 30 20:40:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4R0-0006qn-3V; Tue, 30 Jan 2007 20:38:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4Qw-0006pA-T2 for tls@ietf.org; Tue, 30 Jan 2007 20:38:46 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HC4Qv-0003PH-Bw for tls@ietf.org; Tue, 30 Jan 2007 20:38:46 -0500 Received: (qmail 20649 invoked by uid 0); 31 Jan 2007 01:38:24 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 31 Jan 2007 01:38:24 -0000 Message-Id: <7.0.0.16.2.20070130203255.04bac340@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 30 Jan 2007 20:35:42 -0500 To: martin.rex@sap.com From: Russ Housley Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00< In-Reply-To: <200701300214.DAA20860@uw1048.wdf.sap.corp> References: <7.0.0.16.2.20070129153305.04acb678@vigilsec.com> <200701300214.DAA20860@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin: > > This was long before XMLDSIG effort got under way. The -00 draft > > XML-Signature Requirements document appeared in June 1999. > >The original XMLsig specification seems to prefer Issuer&Serial >for identifying the signer cert -- however due to the stringification >of the issuer name, lookup of the signer cert becomes somewhat difficult, >which might be the reason why WS-Security uses the subject key id >(and includes the entire cert). Many, many things in XMLDSig are based on CMS SignedData. The authors consulted with me several times during the development of the specification. The issues that you raise are unique to XMLDSig. They are not issues in CMS. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 30 23:58:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7Wc-0003Lk-4P; Tue, 30 Jan 2007 23:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7Wb-0003Lf-4q for tls@ietf.org; Tue, 30 Jan 2007 23:56:49 -0500 Received: from bay0-omc3-s18.bay0.hotmail.com ([65.54.246.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7WX-0008Ds-JG for tls@ietf.org; Tue, 30 Jan 2007 23:56:49 -0500 Received: from BAY126-W2 ([65.55.131.37]) by bay0-omc3-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 30 Jan 2007 20:56:45 -0800 X-Originating-IP: [70.142.20.165] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , Russ Housley Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Tue, 30 Jan 2007 20:56:45 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2007 04:56:45.0141 (UTC) FILETIME=[34C56850:01C744F4] X-Spam-Score: 2.4 (++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0819271127==" Errors-To: tls-bounces@lists.ietf.org --===============0819271127== Content-Type: multipart/alternative; boundary="_96150018-d743-4b51-ab4d-ac615e94898b_" --_96150018-d743-4b51-ab4d-ac615e94898b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > > Subject key identifiers were added to CMS by me. They were not in > > P= KCS #7 as specified by RSA Labs. They first appeared in > > draft-ietf-smim= e-cms-10.txt in December 1998. They were added in > > recognition that the = combination of issuer name and serial number was > > quite large. FYI:- The issues are much older than 1998. http://www.imc.org/ietf-pkix/old= -archive-93-96/msg00249.html =20 Its quite true that the original PKCS#7 used DN+serial to refer to keys. A = few billion cert citations later, its been amazingly successful though. Its= hard to know which generates more bytes, certs, or arguments against this = or that feature of the cert specification. =20 I'm personally delighted Russ ran with the PKCS#7 initiative , updated it a= ll a bit, and made CMS - though its true I've personally never used it, giv= en PKCS#10 and PKCS#7 in a simple email do 80% of the job just fine - like = PEM's equivalents predicted. I got PKCS#7 into S/MIME (Windows), PKCS#7 SCE= P (cisco routers worldwide), and PKCS#7 into CMS (US govt key management, M= SFT Cert Server). Much better engineers than me took over and made it work = properly. But boy, was it hard road of (emotional level) argument to get fo= lks to do the "right thing".=20 =20 Sometimes its a real advantage being really dumb (UK "thick"), like me. The= re was something just "right" about PKCS#7 when I first saw it (and Djamal = Hadj Sadok re-implemented it) in 1993. No religion, no agenda, no posturing= , no red/black, no I hate ASN.1 because its foreign .... just clarity - for= implementors attempting to build open systems. =20 I was fortunate enough to see the RSADSI source code, and meet the 2 of fol= k (both vietnamese refugees) who wrote the C classes for the first implemen= tation of PKCS#7 (which did its own virtual functions, with incredibly conv= oluted C macros). What was amazing was the way in which the original code b= ase and the spec aligned. They were like two sides of the same coin, once y= ou learned to appreciate the architecture of the code base. =20 One of the unfortunate sideefects of the the subject cert referring to its = parent cert via a hash is that it destroyed the best bit that DARPA design = folk ever added to certs: the ability to have multiple paths through a semi= -hierarchical CA graph, where a caching scheme could select the best path t= hat fit - based on the context (like routing) and heuristics. With static c= itation of certs paths, we lost the best of what certs really ever had to o= ffer. I'm really not sure static back-references to certs were that good an= idea, except for enforcing control. _________________________________________________________________ Check out all that glitters with the MSN Entertainment Guide to the Oscars http://Movies.msn.com/movies/oscars2007= --_96150018-d743-4b51-ab4d-ac615e94898b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
> > Subject key identifiers were added to CMS by me. They were not in=
> > PKCS #7 as specified by RSA Labs. They first appeared in > > draft-ietf-smime-cms-10.txt in December 1998. They were added in=
> > recognition that the combination of issuer name and serial n= umber was
> > quite large.

FYI:- The issues are much older than 1998. http://www.imc.org/ietf-pkix/o= ld-archive-93-96/msg00249.html
 
Its quite true that the original PKCS#7 used DN+serial to refer to keys. A = few billion cert citations later, its been amazingly successful though. Its= hard to know which generates more bytes, certs, or arguments against this = or that feature of the cert specification.
 
I'm personally delighted Russ ran with the PKCS#7 in= itiative , updated it all a bit, and made CMS - though its true I've person= ally never used it, given PKCS#10 and PKCS#7 in a simple email do= 80% of the job just fine - like PEM's equivalents predicted. I got PKCS#7 into S/MIME (Windows), PKCS#7 SCEP (cisco route= rs worldwide), and PKCS#7 into CMS (US govt key management, MSFT Cert Serve= r). Much better engineers than me took over and made it work properly. But = boy, was it hard road of (emotional level) argument to get folks to do the = "right thing".
 
Sometimes its a real advantage being really dumb (UK "thick"), like me. The= re was something just "right" about PKCS#7 when I first saw it (and Djamal = Hadj Sadok re-implemented it) in 1993. No religion, no agenda, no posturing= , no red/black, no I hate ASN.1 because its foreign .... just clarity - for= implementors attempting to build open systems.
 
I was fortunate enough to see the RSADSI source code, and meet the 2 of fol= k (both vietnamese refugees) who wrote the C classes for the first implemen= tation of PKCS#7 (which did its own virtual functions, with incredibly conv= oluted C macros). What was amazing was the way in which the original code b= ase and the spec aligned. They were like two sides of the same coin, once y= ou learned to appreciate the architecture of the code base.
 
One of the unfortunate sideefects of the the subject cert referring to its = parent cert via a hash is that it destroyed the best bit that DARPA design = folk ever added to certs: the ability to have multiple paths through a semi= -hierarchical CA graph, where a caching scheme could select the best path t= hat fit - based on the context (like routing) and heuristics. With static c= itation of certs paths, we lost the best of what certs really ever had to o= ffer. I'm really not sure static back-references to certs were that go= od an idea, except for enforcing control.

Invite your mail c= ontacts to join your friends list with Windows Live Spaces. It's easy! Try it! = --_96150018-d743-4b51-ab4d-ac615e94898b_-- --===============0819271127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0819271127==-- From tls-bounces@lists.ietf.org Wed Jan 31 12:51:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJae-0000LV-7H; Wed, 31 Jan 2007 12:49:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJaX-0000DH-N3 for tls@ietf.org; Wed, 31 Jan 2007 12:49:41 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJW6-0004T0-0X for tls@ietf.org; Wed, 31 Jan 2007 12:45:08 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0VHixZI028752 for ; Wed, 31 Jan 2007 12:45:00 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Wed, 31 Jan 2007 12:44:59 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Jan 2007 12:44:59 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00< Date: Wed, 31 Jan 2007 12:44:58 -0500 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00< Thread-Index: AcdE9IbtyxShYsp2QuWlLdl9fuPcxAASYboQ From: "Kemp, David P." To: X-OriginalArrivalTime: 31 Jan 2007 17:44:59.0642 (UTC) FILETIME=[873C15A0:01C7455F] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14968003 X-TM-AS-Result: : Yes--10.764100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDIw?= =?us-ascii?B?NzEtNzAwMDM2LTcwMDA3My0xMzkwMTAtMTA2NjYwLTcwMjUyMC0x?= =?us-ascii?B?MTQyODktNzAzNzc4LTcwNjI5MC03MTE0ODItNzAwNzA2LTcwNjg5?= =?us-ascii?B?MS0xMTMyMjgtNzExODYzLTcwMjcyNi03MDE2MTgtNzAyMTA2LTcx?= =?us-ascii?B?MDkxMC03MDEyMjAtNzAxNzM4LTcwODc5Mi03MDI3MDItNzAzNzQ3?= =?us-ascii?B?LTcwMjc2Mi03MDQ5OTQtNzA1ODYxLTcwMjgwNy0xODgxMjEtMTA1?= =?us-ascii?B?MjUwLTcwMTk4MS03MDY1NjQtNzAyMDU0LTExNDY0Ni03MDQwNDgt?= =?us-ascii?B?MTQ4MDUxLTIwMDQw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org ________________________________________ From: Peter Williams [mailto:home_pw@msn.com]=20 > One of the unfortunate sideefects of the the subject cert referring > to its parent cert via a hash is that it destroyed the best bit > that DARPA design folk ever added to certs: the ability to have > multiple paths through a semi-hierarchical CA graph, where a > caching scheme could select the best path that fit - based on the > context (like routing) and heuristics. With static citation of > certs paths, we lost the best of what certs really ever had to > offer. I'm really=A0not sure static back-references to certs were > that good an idea, except for enforcing control. Peter, What has been destroyed? If there are multiple valid paths through a graph to a subject, then all parents of that subject must have the same public key regardless of whether SKI/AKI are populated. In other words, the certificate signature is already a static back-reference to its parent cert(s). (btw, there are no forward references at all - no data object that lists all certs issued by a CA. They can only be discovered, not enumerated.) No single AKI/SKI failure will cause any problem at all; two independent failures are required to preclude acceptance of valid paths: 1) CAs issue certs with incorrect values (CA A issues cert to CA B containing SKI that does not match the AKI of certs issued by CA B), and 2) applications check SKI/AKI chaining during path validation, violating of the 3280 expectation that they not do so. Now whether the extra bandwidth of using SKI/AKI is justified by occasionally saving some computation is a different question; the answer depends on context. Dave (who must be even thicker, having learned and internalized many of Peter's lessons and undoubtedly forgotten many others.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 31 13:36:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKJJ-0003i5-4Y; Wed, 31 Jan 2007 13:35:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKJH-0003fz-Ve for tls@ietf.org; Wed, 31 Jan 2007 13:35:55 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCKJB-00032r-OO for tls@ietf.org; Wed, 31 Jan 2007 13:35:55 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 70BEEB2350 for ; Wed, 31 Jan 2007 13:36:04 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 3DE29B2343 for ; Wed, 31 Jan 2007 13:36:04 -0500 (EST) Message-ID: <45C0E163.5070300@pobox.com> Date: Wed, 31 Jan 2007 10:35:15 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] SHA-224, etc. References: <45BEDD56.8060101@pobox.com> In-Reply-To: <45BEDD56.8060101@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Since I got no responses, I decided to add a certificate signed with RSA/SHA-256 to my test server. If you connect to https://www.mikestoolbox.org, it will use that cert. Mike I wrote: > Does anyone know of a TLS server that sends a > certificate containing a signature using any > of the newer SHA algorithms? I just added > support for them and want to make sure my code > works. > > Thanks, > > Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 31 13:39:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKM1-0005x1-Bl; Wed, 31 Jan 2007 13:38:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKLz-0005wu-GX for tls@ietf.org; Wed, 31 Jan 2007 13:38:43 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCKLv-00044B-9l for tls@ietf.org; Wed, 31 Jan 2007 13:38:43 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 18AE9B2353 for ; Wed, 31 Jan 2007 13:39:01 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id D9C33B2321 for ; Wed, 31 Jan 2007 13:39:00 -0500 (EST) Message-ID: <45C0E214.5020706@pobox.com> Date: Wed, 31 Jan 2007 10:38:12 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] SHA-224, etc. References: <45BEDD56.8060101@pobox.com> <45C0E163.5070300@pobox.com> In-Reply-To: <45C0E163.5070300@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I forgot to mention that you need to send it a server name extension of www.mikestoolbox.org for it to respond with the SHA-256 cert since it shares an IP address with www.mikestoolbox.net (which uses SHA-1). Mike I wrote: > Since I got no responses, I decided to add a certificate > signed with RSA/SHA-256 to my test server. If you connect > to https://www.mikestoolbox.org, it will use that cert. > > Mike > > > I wrote: >> Does anyone know of a TLS server that sends a >> certificate containing a signature using any >> of the newer SHA algorithms? I just added >> support for them and want to make sure my code >> works. >> >> Thanks, >> >> Mike > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 31 21:19:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRW4-0000r7-B1; Wed, 31 Jan 2007 21:17:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRW1-0000qk-Jk; Wed, 31 Jan 2007 21:17:33 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCRVz-0001Rg-70; Wed, 31 Jan 2007 21:17:33 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l112HUsr011852; Wed, 31 Jan 2007 18:17:30 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l112HUMs011851; Wed, 31 Jan 2007 18:17:30 -0800 Date: Wed, 31 Jan 2007 18:17:30 -0800 Message-Id: <200702010217.l112HUMs011851@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 4785 on Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4785 Title: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) Author: U. Blumenthal, P. Goel Status: Standards Track Date: January 2007 Mailbox: urimobile@optonline.net, Purushottam.Goel@intel.com Pages: 5 Characters: 9550 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-psk-null-03.txt URL: http://www.rfc-editor.org/rfc/rfc4785.txt This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS TRACK] This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls