Re: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08

Eric Rescorla <ekr@networkresonance.com> Tue, 16 May 2006 21:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6ho-00054X-ED; Tue, 16 May 2006 17:03:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6hn-00054S-5o for tls@lists.ietf.org; Tue, 16 May 2006 17:03:47 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6hm-0007DH-Rf for tls@lists.ietf.org; Tue, 16 May 2006 17:03:47 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id F21EE1E8C1F; Tue, 16 May 2006 14:03:45 -0700 (PDT)
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Subject: Re: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08
References: <B356D8F434D20B40A8CEDAEC305A1F2402A7978F@esebe105.NOE.Nokia.com> <87slna3wkc.fsf@latte.josefsson.org> <86mzdiowgo.fsf@raman.networkresonance.com> <200605161907.51448.nmav@gnutls.org> <20060516165736.ddc57b83.smb@cs.columbia.edu>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Tue, 16 May 2006 14:03:45 -0700
In-Reply-To: <20060516165736.ddc57b83.smb@cs.columbia.edu> (Steven M. Bellovin's message of "Tue, 16 May 2006 16:57:36 -0400")
Message-ID: <867j4lptqm.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: tls@lists.ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
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

"Steven M. Bellovin" <smb@cs.columbia.edu> writes:

> On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos
> <nmav@gnutls.org> wrote:
>
>> On Tue 16 May 2006 16:50, Eric Rescorla wrote:
>> 
>> > > I'd disagree that it is that simple to fix that: If the draft
>> > > permit more than one key, I believe it has to describe how
>> > > implementations are supposed to use more than one key to build the
>> > > chain, or at least mandate some specific behaviour.
>> > I don't agree with this. PGP at least theoretically knows how
>> > to build cert chains from a "bucket of keys".
>> 
>> Maybe but I still find no point in sending a bucket of keys just like 
>> that. If it is to be sent it has to be clearly defined what it is 
>> expected in this bucket and so on. I'm quite reluctant to do it because 
>> I don't need nor find a use for this functionality. It can be easily 
>> added by anyone that need it[0], and I would be willing to include the 
>> required changes in this or a future update, if somebody needs it and 
>> defines the semantics of a key list.
>> 
> The problem is that you don't know the recipient's trust anchors or trust
> metrics.  Without that, you have to send the whole graph (or at least as
> much of it as you have), to maximize the chances of the key being accepted.

Right, I understand that this is a problem in principle, but I'm
not sure that it's a problem in practice. In particular, I'm not
sure that it's so bad a problem in practice that the protocol should
be explicitly designed to prohibit people who think they understand
the trust graph from giving hints.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls