Re: [TLS] Request for review: Next Protocol Negotiation Extension

Eric Rescorla <ekr@rtfm.com> Tue, 17 August 2010 04:52 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D39B3A67E5 for <tls@core3.amsl.com>; Mon, 16 Aug 2010 21:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.18
X-Spam-Level:
X-Spam-Status: No, score=-101.18 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlAR+kLR+VU4 for <tls@core3.amsl.com>; Mon, 16 Aug 2010 21:52:16 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E76133A67A4 for <tls@ietf.org>; Mon, 16 Aug 2010 21:52:15 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2527571bwz.31 for <tls@ietf.org>; Mon, 16 Aug 2010 21:52:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.177.79 with SMTP id bh15mr4024220bkb.121.1282020771088; Mon, 16 Aug 2010 21:52:51 -0700 (PDT)
Received: by 10.204.7.70 with HTTP; Mon, 16 Aug 2010 21:52:51 -0700 (PDT)
In-Reply-To: <4C6A001C.3080305@pobox.com>
References: <AANLkTi=5H_0hGzxMmfNU0hLS=5psW6J3c2to756OT--7@mail.gmail.com> <4C6978A3.1070404@pobox.com> <001301cb3d71$295b28f0$7c117ad0$@briansmith.org> <AANLkTi=h8extMyA-U42XNdvhV4S0gUJFpnM7Pn5bu35F@mail.gmail.com> <4C6A001C.3080305@pobox.com>
Date: Mon, 16 Aug 2010 21:52:51 -0700
Message-ID: <AANLkTi=x1uECZkAOSNjDU4P4MK-_AyT6LYsXB9=3pogz@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Michael D'Errico <mike-list@pobox.com>
Content-Type: multipart/alternative; boundary="0016e6d7effba7c805048dfdb8f1"
Cc: tls@ietf.org
Subject: Re: [TLS] Request for review: Next Protocol Negotiation Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2010 04:52:17 -0000

Without taking a position on whether extensions are cheap or not,
I would observe that certificates can contain [extended] key usage
extensions, precisely to avoid e.g., a Web certificate being
used for a SIP server. So, I don't think Michael's concern here is
totally unfounded.

-Ekr



On Mon, Aug 16, 2010 at 8:21 PM, Michael D'Errico <mike-list@pobox.com>wrote:

> Adam Barth wrote:
>
>>
>> Why should the server's certificate vary depending on what the next
>> protocol is?  Your colleague Brian Smith appears to hold the opposite
>> belief.  Keep in mind that TLS extensions are cheap.  If that need
>> arises in the future, we design another next-protocol negotiation
>> extension to meet that need.
>>
>
> In the 7 years since RFC 3546, there have been only 17 TLS extensions
> defined.  I don't know what gave you the idea that they are "cheap."
> Each one needs to be carefully studied to determine how they interact
> with each other.
>
> So, no, we won't define one haphazardly.
>
> But to answer your question, I'm not saying that a certificate "should"
> depend on the protocol, but it "might" and you should accommodate that.
>
> Once you start multiplexing many services all on a single port, it would
> actually be surprising to find that they all have the exact same security
> requirements and can all use the same certificates and keys.
>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>