Re: [TLS] TLS 1.2 hash agility
Eric Rescorla <ekr@networkresonance.com> Thu, 27 September 2007 14:34 UTC
Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauRY-0004Qk-EL; Thu, 27 Sep 2007 10:34:20 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauRW-0004Om-Pi for tls@ietf.org; Thu, 27 Sep 2007 10:34:18 -0400
Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IauRW-0002qb-BC for tls@ietf.org; Thu, 27 Sep 2007 10:34:18 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7EF4433C21; Thu, 27 Sep 2007 07:30:28 -0700 (PDT)
Date: Thu, 27 Sep 2007 07:30:28 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Mike <mike-list@pobox.com>
Subject: Re: [TLS] TLS 1.2 hash agility
In-Reply-To: <46FBBBBE.7000108@pobox.com>
References: <46ABB82D.8090709@pobox.com> <46ACCCCB.8000201@pobox.com> <B356D8F434D20B40A8CEDAEC305A1F24046B2496@esebe105.NOE.Nokia.com> <20070914215611.0342933C21@delta.rtfm.com> <46EB102E.2070900@pobox.com> <20070914225606.9E9B433C21@delta.rtfm.com> <46EC2AE7.9040903@pobox.com> <20070917185820.6E7CC33C3A@delta.rtfm.com> <46FA745A.3070305@pobox.com> <20070926152907.8A60B33C23@delta.rtfm.com> <46FA91E8.5020303@pobox.com> <46FB4397.6040203@pobox.com> <46FBBBBE.7000108@pobox.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20070927143028.7EF4433C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
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." <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
At Thu, 27 Sep 2007 07:18:38 -0700, Mike wrote: > > > I spent [a lot of time] trying to come up with other valid > > reasons for using the extension to advertise the server's > > capabilities, versus putting them in the CertificateRequest. The > > only thing I could come up with is that putting the list of > > signature algorithms in the CertificateRequest is a change to the > > format of that message, so it requires version-specific processing, > > whereas if you use the server extension, the format of Certificate > > Request is the same as previous TLS versions. > > I came up with a few more ideas, unfortunately at the expense of > not being able to sleep: > > - The extension mechanism was added to TLS to enable the > addition of functionality without needing to constantly > change handshake message formats; so I would argue that > any functionality that -can- be added using an extension > -should- use an extension instead of modifying messages. > (Yes, Signature had to change so messages will be > different, but limiting the damage is a worthy goal.) No, I don't agree with this claim about the purpose of the extension mechanism. Some things are appropriately done in extensions, some should be part of the main protocol. It's a *bad* idea to move as much as possible into extensions. > - There is a potential performance benefit on the client > side: if the client requires better algorithms than the > defaults and the server either doesn't reply with the > extension, or if the list doesn't contain an acceptable > algorithm, then the client can abort the connection > immediately after parsing the ServerHello message. It > can avoid the need to parse the Certificate message to > determine how it was signed. As you indicated in your previous message, this is not in fact an advantage. > The only counter argument I could find is that the server's list > of acceptable algorithms might be different in different places. And yet, I mentioned several other reasons in my previous message: - Locality of information. - It works even if the client does not offer the extension. > Even if so, the client can benefit from knowing the server's > certificate signature algorithms up front, so having the server > respond with the extension is useful. I don't see any significant value in this. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] TLS 1.2 Eric Rescorla
- Re: [TLS] TLS 1.2 Steven M. Bellovin
- Re: [TLS] TLS 1.2 Peter Gutmann
- Re: [TLS] TLS 1.2 Steven M. Bellovin
- Re: [TLS] TLS 1.2 Bodo Moeller
- [TLS] TLS 1.2 Mike
- [TLS] TLS 1.2 Mike
- [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 Mike
- [TLS] TLS 1.2 MAC calculation Mike
- Antwort: [TLS] TLS 1.2 MAC calculation Axel.Heider
- Re: Antwort: [TLS] TLS 1.2 MAC calculation Bodo Moeller
- Re: [TLS] TLS 1.2 interoperating Mike
- RE: [TLS] TLS 1.2 hash agility Pasi.Eronen
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- RE: [TLS] TLS 1.2 hash agility Pasi.Eronen
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Mike
- RE: [TLS] TLS 1.2 hash agility Pasi.Eronen
- RE: [TLS] TLS 1.2 hash agility Pasi.Eronen
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Mike
- Re: [TLS] TLS 1.2 hash agility Eric Rescorla
- RE: [TLS] TLS 1.2 hash agility Russ Housley
- RE: [TLS] TLS 1.2 hash agility Pasi.Eronen
- RE: [TLS] TLS 1.2 hash agility Pasi.Eronen