IETF Logo Mail Archive

Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

Steve Schultze <sjs@princeton.edu> Thu, 16 December 2010 04:52 UTC

Return-Path: <sjs@princeton.edu>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9018828C13B for <keyassure@core3.amsl.com>; Wed, 15 Dec 2010 20:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bjhEBVXiGnL3 for <keyassure@core3.amsl.com>; Wed, 15 Dec 2010 20:52:37 -0800 (PST)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 1575028C121 for <keyassure@ietf.org>; Wed, 15 Dec 2010 20:52:32 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id oBG4sGG4032249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <keyassure@ietf.org>; Wed, 15 Dec 2010 23:54:16 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBG4sF8L010907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <keyassure@ietf.org>; Wed, 15 Dec 2010 23:54:16 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze <sjs@princeton.edu>
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
Date: Wed, 15 Dec 2010 23:54:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <407C0083-DBBF-463E-B1DF-A3041CDE1E13@princeton.edu>
References: <20101213220001.24500.52050.idtracker@localhost>
To: keyassure@ietf.org
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012150228
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Dec 2010 04:52:39 -0000

"If the application receives zero usable certificate associations, it processes TLS in the normal fashion."

I think that this should read:
"If the application receives zero usable certificate associations, it [MAY process] TLS in the normal fashion."

I originally made this suggestion on draft-hoffman-keys-linkage-from-dns-03 (see the follow-on discussion here for background):
http://www.ietf.org/mail-archive/web/keyassure/current/msg00890.html

And, as I noted during our session in Beijing, the motivation for permitting the client to choose is that if we mandate it one way or the other, we fall into a trap.  If the client MUST process TLS in the normal fashion (aka, using PKIX) then we have provided a solution that is no better than the status quo.  If the client MUST give an "access_denied" error, then nobody will use the standard early on in deployment because the majority of sites will be unreachable.

v2.23.0 | Report a Bug | By Email