Re: [TLS] Consensus call for certificate URL extension

[Alfred Hönes <ah at tr-sys.de>]

At Thu, 25 Sep 2008 09:24:25 +0200 , Simon Josefsson wrote:
> If the assumption in (B), that there are no known deployments of this
> extension, is correct, my preference is to deprecate the extension,
> without creating a new extension with different properties.
> 
> The way I am reading the replies so far imply that few if anyone really
> needs this extension.  If that is the case, I don't see why we need to
> spend time on it.

Under these circumstances, I fully support this variant, '(A-)':
Deprecate the extension.  Full stop.

If we ever want to go for Draft Standard with TLS (I hope we do),
we'll need interoperable implementations anyway, or leave the
Cert URL extension out of the specification (cf. RFC 2026).

So better deprecate it now than later, to save implementation
efforts not really needed now and hence never going to be tested
thoroughly -- another security concern.

Our primary focus now should be to hurry up with 4366-bis, in order to
deliver to the community a consistent set of successors to 4346+4366.

Please recall that TLS 1.2, RFC 5246, already has officially Obsoleted
RFC 4366, increasing the pressure to timely restore a consistent
publication state.
Thus, arguably currently anything in RFC 4366 not incorporated into
RFC 5246 can be regarded as obsoleted anyway, from a very formalistic
point of view.


Pasi has reminded me of my past general input regarding hash
algorithm agility for TLS extensions, which has been tracked
as #46 -- I almost had forgotten that in the meantime!  :-)

Deprecating the Cert URL extension now will solve this problem in
the most time- and sweat-conserving manner possible, leaving the
issue to future work, if any.

If anybody once comes up with a killFrom tls-bounces at ietf.org  Thu Sep 25 07:55:09 2008
Return-Path: <tls-bounces at ietf.org>
X-Original-To: tls-archive at ietf.org
Delivered-To: ietfarch-tls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E95953A6774;
	Thu, 25 Sep 2008 07:55:09 -0700 (PDT)
X-Original-To: tls at core3.amsl.com
Delivered-To: tls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B22CA3A6837
	for <tls at core3.amsl.com>; Thu, 25 Sep 2008 07:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.251
X-Spam-Level: *
X-Spam-Status: No, score=1.251 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35,
	MIME_8BIT_HEADER=0.3]
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 M6oEflj0z6Mw for <tls at core3.amsl.com>;
	Thu, 25 Sep 2008 07:55:09 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147])
	by core3.amsl.com (Postfix) with ESMTP id CFEE63A6767
	for <tls at ietf.org>; Thu, 25 Sep 2008 07:55:07 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP
	($Revision: 1.37.109.26 $/16.3) id AA122274397;
	Thu, 25 Sep 2008 16:53:17 +0200
Received: (from ah at localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id
	QAA26824; Thu, 25 Sep 2008 16:53:12 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah at tr-sys.de>
Message-Id: <200809251453.QAA26824 at TR-Sys.de>
To: tls at ietf.org
Date: Thu, 25 Sep 2008 16:53:12 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: Re: [TLS] Consensus call for certificate URL extension
X-BeenThere: tls at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:tls at ietf.org>
List-Help: <mailto:tls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
	<mailto:tls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces at ietf.org
Errors-To: tls-bounces at ietf.org

At Thu, 25 Sep 2008 09:24:25 +0200 , Simon Josefsson wrote:
> If the assumption in (B), that there are no known deployments of this
> extension, is correct, my preference is to deprecate the extension,
> without creating a new extension with different properties.
> 
> The way I am reading the replies so far imply that few if anyone really
> needs this extension.  If that is the case, I don't see why we need to
> spend time on it.

Under these circumstances, I fully support this variant, '(A-)':
Deprecate the extension.  Full stop.

If we ever want to go for Draft Standard with TLS (I hope we do),
we'll need interoperable implementations anyway, or leave the
Cert URL extension out of the specification (cf. RFC 2026).

So better deprecate it now than later, to save implementation
efforts not really needed now and hence never going to be tested
thoroughly -- another security concern.

Our primary focus now should be to hurry up with 4366-bis, in order to
deliver to the community a consistent set of successors to 4346+4366.

Please recall that TLS 1.2, RFC 5246, already has officially Obsoleted
RFC 4366, increasing the pressure to timely restore a consistent
publication state.
Thus, arguably currently anything in RFC 4366 not incorporated into
RFC 5246 can be regarded as obsoleted anyway, from a very formalistic
point of view.


Pasi has reminded me of my past general input regarding hash
algorithm agility for TLS extensions, which has been tracked
as #46 -- I almost had forgotten that in the meantime!  :-)

Deprecating the Cert URL extension now will solve this problem in
the most time- and sweat-conserving manner possible, leaving the
issue to future work, if any.

If anybody once comes up with a killer need, they can cause a
resurrection of the extension (or the underlying idea), come up
with a new document, plug in algorithms as needed and 'en vogue',
and figure out the security issues.


Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls


er need, they can cause a
resurrection of the extension (or the underlying idea), come up
with a new document, plug in algorithms as needed and 'en vogue',
and figure out the security issues.


Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls