Re: [TLS] Updated TLS 1.2 I-D

"Anyang Ren" <anyang.ren@gmail.com> Tue, 27 June 2006 14:21 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvERV-0002JR-NX; Tue, 27 Jun 2006 10:21:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvERU-0002GI-L0 for tls@ietf.org; Tue, 27 Jun 2006 10:21:28 -0400
Received: from nz-out-0102.google.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvERR-0001G0-DF for tls@ietf.org; Tue, 27 Jun 2006 10:21:28 -0400
Received: by nz-out-0102.google.com with SMTP id o1so202687nzf for <tls@ietf.org>; Tue, 27 Jun 2006 07:21:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=olYbmOtj3lhNvvTXtQNXWD2R8ovQangC4L5vPbcYGDKpqpniDObcWJBCCm+npXaWKSF4QINX85F4Rsel05pwgkQRuYalQ4wO2jeP20tEgw+zig6k7au1yLJFJg/WN3nEO4AvJ/HIGV4asMeAte8wJxXeBYt2o/c1rbKnR4BYUOE=
Received: by 10.36.12.12 with SMTP id 12mr769401nzl; Tue, 27 Jun 2006 07:21:25 -0700 (PDT)
Received: by 10.36.80.13 with HTTP; Tue, 27 Jun 2006 07:21:24 -0700 (PDT)
Message-ID: <39932b4c0606270721v19ecbed6j5fe129a42a99f106@mail.gmail.com>
Date: Tue, 27 Jun 2006 07:21:24 -0700
From: "Anyang Ren" <anyang.ren@gmail.com>
To: tls@ietf.org
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=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060625170241.E4704222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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." <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

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

In Section 1.1 Differences from TLS 1.1, you have:

     - Replacement of MD5/SHA-1 combination in the PRF

     - Replacement of MD5/SHA-1 combination in the digitally-signed
     element.

Are you going to replace the MD5/SHA-1 combination in the
verify_data field of the Finished message?

The "Hash" algorithm used in RSA signatures is the same hash
algorithm used in the signature of the certificate.  Although this
is a simple way to choose the "Hash" algorithm, the chosen hash
algorithm really reflects the capability of the CA that issued the
certificate as opposed to the capability of the certificate's subject
(the server or the client). For example, the CA may sign a server
certificate that contains an RSA public key using DSA, and "Hash"
would be SHA-1 because the signature of the certificate is a DSA
signature.

The DSS signatures are hardcoded to use SHA-1. Are you planning
to support extensions of DSA for the SHA-2 algorithms (as in Draft
FIPS 186-3)?

Any interest in adding SHA-384 to the enumerated HashType defined
in 7.4.1.4.7? The current definition of HashType seems to imply that
CAs don't plan to sign certificates with SHA-384 in the signatures.

Anyang Ren
Open source developer

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls