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