Subject: Call for discussion topics for Apps Area meeting in Hiroshima

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Oct 2009 13:42:34 +0000

Hi,
This is a [late] call for discussion topics for Hiroshima. Please send 
your requests to Lisa and myself.

Regards,
Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2009 08:49:42 -0600

> your requests to Lisa and myself.

I'd like to discuss draft-saintandre-tls-server-id-check so that we can
get closer to consensus about what exactly we want to cover in that I-D
and whether we need additional I-Ds for related topics.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Oct 2009 12:12:18 -0400

> and whether we need additional I-Ds for related topics.

If I read the draft correctly:

    "If a client wishes to connect to a server securely, it needs to check
    the identity of the server so that it can determine if the server is
    what it claims to be"

seems to be the salient statement about the problem to be solved.

Can you elaborate a bit? I'm only looking for a somewhat more extensive spec of 
your topic goal, rather than trying resolving it, here.

Tnx.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2009 11:46:49 -0600

On 10/28/09 10:12 AM, Dave CROCKER wrote:
> Can you elaborate a bit? I'm only looking for a somewhat more extensive
> spec of your topic goal, rather than trying resolving it, here.

We seem to have discussed several possibilities:

1. Define how an application client checks its expectations ("reference
identity" = domain name or IP address) against what the application
server presents in a CA-issued certificate. We have a great deal of
experience with this model in HTTP, IMAP, LDAP, XMPP, and so on. It
seems valuable to abstract from those instances to form a more general
conception of how an application client should check the identity of an
application server.

2. Other application protocols (SSH, Netconf, SysLog, etc.) use keys
instead of X.509 certs. Here the application client needs to bootstrap
some notion of trust (which might be "leap of faith" in the presented
key) and then in the future simply verify that the same association
continues to hold (i.e., there is no concept of a "reference identity"
here). It appears that some folks would like to specify this in the same
document, whereas others want to specify it separately.

3. Other application protocols (DTLS, XMPP, etc.) enable one client to
communicate with another client in a way that enables end-to-end
security. Here the credentials might be keys or certs, but I think more
typically keys, in which case the fingerprint verification model might
apply (except that the identity being checked is not an application
server but a peer client).

There are, no doubt, questionable assumptions lurking in the summary
I've provided, which is why I think it makes sense to discuss this in
Hiroshima.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "tom.petch" <[email-masked]>
Date: Wed, 28 Oct 2009 18:18:52 +0100

----- Original Message -----
From: "Dave CROCKER" <[email-masked]>
Sent: Wednesday, October 28, 2009 5:12 PM
> your topic goal, rather than trying resolving it, here.

Dave

We did discuss scope back in June without anything very concrete
emerging, apart from limiting ourselves to X.509, but there was a
faint consensus for a cookbook that other RFC would then refer to,
selecting a profile, when wanting to verify that a certificate received
over a security protocol matched something that the box had 'configured'
into it.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 29 Oct 2009 11:22:26 +0100

----- Original Message ----- 
From: "Peter Saint-Andre" <[email-masked]>
Sent: Wednesday, October 28, 2009 6:46 PM

Peter

The comments I have made relate solely to use of X.509 certificates
with NETCONF, syslog, isms etc, nothing to do with public keys ie 
the validation of X.509 certificate against reference identity with these
protocols.

I would widen the reference identity beyond DNS and IP, to eg
URL and MAC.

The other wrinkle is the use of a fingerprint in order to avoid the need
to use CA/CRL/OCSP etc but again, this is for a pukka X.509 certificate
which would then be subject to checking against a reference identity
as above.

Tom Petch