Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt
<home_pw@msn.com> Thu, 18 January 2007 06:10 UTC
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: <BAY126-DAV20B318C71166653C6AACD092AA0@phx.gbl>
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: home_pw@msn.com
To: EKR <ekr@networkresonance.com>
References: <45AEA795.2080308@redhat.com><BAY126-DAV192028B2EA5EB9D23929D892AA0@phx.gbl> <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 <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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
----- Original Message ----- From: "Eric Rescorla" <ekr@networkresonance.com> To: <home_pw@msn.com> Cc: "Wan-Teh Chang" <wtchang@redhat.com>; "tls mailing list" <tls@ietf.org> Sent: Wednesday, January 17, 2007 9:12 PM Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt > <home_pw@msn.com> 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
- [TLS] Review comments on draft-rescorla-tls-opaqu… Wan-Teh Chang
- Re: [TLS] Review comments on draft-rescorla-tls-o… home_pw
- Re: [TLS] Review comments on draft-rescorla-tls-o… home_pw
- Re: [TLS] Review comments on draft-rescorla-tls-o… Eric Rescorla
- Re: [TLS] Review comments on draft-rescorla-tls-o… home_pw
- Re: [TLS] Review comments on draft-rescorla-tls-o… Eric Rescorla