Re: [TLS] Updated TLS 1.2 I-D
"Kyle Hamilton" <aerowolf@gmail.com> Mon, 26 June 2006 05:21 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujXI-0000Mg-PB; Mon, 26 Jun 2006 01:21:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujXG-0000Ma-Uv for tls@ietf.org; Mon, 26 Jun 2006 01:21:22 -0400
Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FujXE-0006xQ-JP for tls@ietf.org; Mon, 26 Jun 2006 01:21:22 -0400
Received: by nf-out-0910.google.com with SMTP id d4so815066nfe for <tls@ietf.org>; Sun, 25 Jun 2006 22:21:19 -0700 (PDT)
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=bXW1u62yowKrFm7bBiGHkIziWQf8fqnSvK7uZ/Wiwa3ptqfd9Gz47vbbGmoQ6D7Qh6dV6a9T7JxlQdq9Ew2r7g9cDxk+qeGE73NXFN0NR/Nd1dVbB9nbjjb3eMEH9wDVKt53JzxjzqW90+cUBMWiAesbKtHGuX9xEt2aq+54LN4=
Received: by 10.48.242.3 with SMTP id p3mr4533791nfh; Sun, 25 Jun 2006 22:21:19 -0700 (PDT)
Received: by 10.48.12.1 with HTTP; Sun, 25 Jun 2006 22:21:19 -0700 (PDT)
Message-ID: <6b9359640606252221g6a26630ew65f34de3beb528d7@mail.gmail.com>
Date: Sun, 25 Jun 2006 22:21:19 -0700
From: Kyle Hamilton <aerowolf@gmail.com>
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [TLS] Updated TLS 1.2 I-D
In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060625170241.E4704222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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." <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
I'm curious, why does having it as an extension make you uncomfortable? The way I see it, the PRF will need to be the same on both sides in order for the handshake to complete, even if it's negotiated via extension. If it's not, then the server (and/or the client) will get what should be the handshake_complete packet, and be unable to decrypt it properly. When they do, they'll run the hash over it, see that it doesn't match, and throw a decrypt_error or decode_error fatal alert. Though this would be a good way for Mallory to mount a DOS attack against the server and/or client (insert an extension to select the PRF), that possibility is already incumbent in the handshake protocol regardless (and has been there since at least TLS 1.0, allowing extra data (which later became 'extensions') after the end of the client_hello). An extension of this type (and let's face it, 'extensions' were introduced so that the protocol could be extended beyond its original capability), even though it is recommended not to be put in place, appears to be cryptographically sound. I've got a couple of comments and questions on the draft (and protocol) itself; I'll put them in a separate email. -Kyle H On 6/25/06, Eric Rescorla <ekr@networkresonance.com> wrote: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt > > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. > > My proposal is as follows: > > - All PRFs must have the same "API" as the existing TLS > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. > > The major alternative is some kind of extension, which makes > me uncomfortable. > > Thoughts? Issues? > -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
- [TLS] Updated TLS 1.2 I-D Eric Rescorla
- Re: [TLS] Updated TLS 1.2 I-D Kyle Hamilton
- Re: [TLS] Updated TLS 1.2 I-D Bodo Moeller
- Re: [TLS] Updated TLS 1.2 I-D Peter Sylvester
- RE: [TLS] Updated TLS 1.2 I-D Pasi.Eronen
- Re: [TLS] Updated TLS 1.2 I-D Eric Rescorla
- Re: [TLS] Updated TLS 1.2 I-D Mohamad Badra
- RE: [TLS] Updated TLS 1.2 I-D Pasi.Eronen
- Re: [TLS] Updated TLS 1.2 I-D Bodo Moeller
- Re: [TLS] Updated TLS 1.2 I-D Peter Sylvester
- RE: [TLS] Updated TLS 1.2 I-D Pasi.Eronen
- Re: [TLS] Updated TLS 1.2 I-D Anyang Ren
- Re: [TLS] Updated TLS 1.2 I-D Eric Rescorla
- Re: [TLS] Updated TLS 1.2 I-D Anyang Ren
- Re: [TLS] Updated TLS 1.2 I-D Eric Rescorla
- RE: [TLS] Updated TLS 1.2 I-D Pasi.Eronen
- Re: [TLS] Updated TLS 1.2 I-D Rob Dugal
- Re: [TLS] Updated TLS 1.2 I-D Gregory Chudov
- Re: [TLS] Updated TLS 1.2 I-D Bodo Moeller