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