Subject: Re: TLS server identity verification

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Jun 2009 10:11:44 +0100

Alexey Melnikov wrote:

> Folks,
> The issue of a document describing recommended text/template for 
> server identity verification procedure came up again while talking 
> about advancing EPP.
>
> As an AD, I would really like for draft-hodges-server-ident-check to 
> be published as an RFC. And I know that Chris was keen on this as well.
> Jeff/Bob, do you have any cycles to work on this?

As I've heard no response from the authors and lots of support from the 
community to work on this, I've asked Kurt Zeilenga and Peter 
Saint-Andre to take over editing of the document.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 3 Jun 2009 09:30:20 +0200

----- Original Message ----- 
From: "Alexey Melnikov" <[email-masked]>
To: "Apps Discuss" <[email-masked]>
Cc: "=JeffH" <[email-masked]>
Sent: Tuesday, June 02, 2009 11:11 AM
Subject: Re: TLS server identity verification

> Saint-Andre to take over editing of the document.

What comes next?

Will they re-issue it?  Will it be put up for adoption as an ietf document?
Or do you want to go straight into comments on the I-D as is?

Tom Petch

> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Jun 2009 08:43:36 -0600

> Or do you want to go straight into comments on the I-D as is?

Kurt and I will work to produce an updated I-D soon, incorporating the
ideas discussed on this list and taking into account text about this
topic from other RFCs and I-Ds (XMPP, SIP, etc.).

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Jun 2009 20:39:13 +0100

>Will they re-issue it?  Will it be put up for adoption as an ietf document?
New editors told me that the first version is just going to be a 
refresh. Then they will work on updating it based on comments.

>Or do you want to go straight into comments on the I-D as is?
Feel free to post your comments here.

(Unless this topic generates lots of traffic, I think it is Ok to 
discuss it on this mailing list.)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Jun 2009 13:53:24 -0600

> refresh. Then they will work on updating it based on comments.

Correct. Kurt and I will work to post a refreshed version this week.
Since it's only a refresh it won't take much time. :)

Peter

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

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Jun 2009 12:26:45 +0200

----- Original Message -----
From: "Alexey Melnikov" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Apps Discuss" <[email-masked]>
Sent: Wednesday, June 03, 2009 9:39 PM
Subject: Re: TLS server identity verification

<snip>

> discuss it on this mailing list.)

Scope; what should it be?

The title is about identity checking in TLS; but that is not what it is about.
The body is about PKI-based interactions.

TLS has several methods for authenticating a server, of which certificates may
be the commonest but is not the only one.

On the other hand, PKI has uses outside TLS.

So I don't like the title and I don't like the body:-)

I would like the scope to be (server identity checking based on)
- certificates and PKI
- certificates without PKI
- public keys
with a title to match.

This view is based on requirements arising from recent work on
- syslog over TLS
- netconf over TLS
- snmp over SSH
- syslog over DTLS.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 5 Jun 2009 08:14:10 -0700

> Scope; what should it be?

Very good question.

My personal opinion is that the document should provide a "cookbook"  
that can be used in creating procedures for TLS server identity  
verification in application protocol technical specifications.

Currently, each application protocol technical specification which  
provides for TLS is to include procedures for TLS server identity  
verification.  It is desirable to have some commonality between the  
methods.   However, as not every way to verify the TLS server identity  
is applicable to every application protocol which uses TLS, I do not  
think it feasible to develop a "generic" procedure (as the previous  
title suggested).

I suggest instead the title "TLS Server Identity Verification in  
Application Protocols", for the document to discuss various ways for  
TLS server identity verification to be done and be organized such that  
application protocol specifications can easily "profile" this document  
in order to specify the application protocol specific procedure.  I  
think the document should be targeted for the Standard Track.

I also think it would be useful to have a document indicating which  
ways are "best current practice", but thinking this might be better  
placed in a separate document.

I do think the document should be narrowly focus on TLS server  
identity verification with X.509 certificates.  I don't mind having a  
title which indicates this narrow focus, but am also fine with a title  
which leaves the "with X.509 certificates" aspect implicit.

-- Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Jun 2009 16:24:05 +0100

Hi Tom,

>This view is based on requirements arising from recent work on
With my individual contributor hat on, I would rather concentrate on TLS 
(and maybe DTLS) server identity verification. If am ambivalent about 
non X.509 TLS certificates.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Jun 2009 18:34:50 +0200

----- Original Message -----
From: "Alexey Melnikov" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Apps Discuss" <[email-masked]>
Sent: Friday, June 05, 2009 5:24 PM

> non X.509 TLS certificates.

I had hoped that DTLS would be taken as read, since I see little or no
difference in the identity checking.

I would like to include X.509 certificates without PKI, as in eg RFC 5425
TLS Transport Mapping for Syslog.

I think that the costs or hassle of PKI that inhibit deployment.

Tom Petch

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jun 2009 11:51:05 -0700

>- certificates without PKI

I would prefer the scope to be "certificates with PKIX certificates" with TLS as an example that runs through the document. The discussion should *not* try to span to other protocols; in specific, IPsec has its own document on how to use PKIX certificates with IKE (which is tortured and burdened with dark history).

Also, there are only two IETF certificates other than PKIX: SPKI has seen essentially no implementation, and OpenPGP is a certificate format but no PKI to support it. I suggest that neither of these need to have a document such as this for them.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Jun 2009 15:16:17 -0500

> - certificates without PKI

I think it'd be fine to have a separate document for each of the above.

> This view is based on requirements arising from recent work on

Well, ideally RFC3280 should suffice.  In practice, in the HTTP world,
people do things that require more text than RFC3280 has in order to
verify server identities.  So I'd like to see a focus on describing
actual practice only, and then primarily (if not only) in the context of
HTTP.  If other protocols also do things outside RFC3280, then let's
have separate documents for those _unless_ those documents are either
going to be copies of this one, or could be made a single page addition
to this one.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 06 Jun 2009 12:37:43 +0200

> Also, there are only two IETF certificates other than PKIX: SPKI has seen essentially no implementation, and OpenPGP is a certificate format but no PKI to support it. I suggest that neither of thes…

Actually, for OpenPGP used in TLS a document like that would be useful.
RFC 5081 doesn't discuss naming or verification or names.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jun 2009 07:53:15 -0700

>RFC 5081 doesn't discuss naming or verification or names.

That's exactly my point. There is an experimental RFC with poor semantics, and a base standard RFC with no PKI. This doesn't seem like a useful foundation for specification that is supposed to help interoperability.

---

From: "tom.petch" <[email-masked]>
Date: Mon, 8 Jun 2009 18:34:06 +0200

----- Original Message -----
From: "Nicolas Williams" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>; <[email-masked]>; "Apps
Discuss" <[email-masked]>
Sent: Friday, June 05, 2009 10:16 PM
Subject: Re: TLS server identity verification

<snip>
> Well, ideally RFC3280 should suffice.

Unfortunately the security ADs do not agree:-( which led to the work in
producing syslog over TLS and netconf over TLS.  I would rather not
reinvent that wheel, rather capture it now before the security ADs change
and we have to start all over again:---(

I was sloppy in saying certificates, I did mean X.509 and not PGP etc, but
want to include the non-PKI case, eg fingerprints.  PKI is a hassle which is
why I see it as a great invention, technically brilliant, but one that may or
may not
take off, one day (IPv6, OSI, Token Ring, ....). So giving users the option of
X.509 with fingerprints just may allow them to introduce security when X.509
with PKI would put them off.  I am a great believer in 'better something than
nothing', fearing that the IETF sets the bar at a level when users opt for
nothing instead.

I do see two distinct parts to this cookbook, one of how do you validate the
certificate (trust anchor, fingerprint, CRL etc); and the other as to what
you do with the contents, which fields, what wildcarding with a set of
alternatives, perhaps of different strengths of security.  This bifurcation is
how the discussion (and DISCUSS) panned out with the I-Ds I have been involved
with.

I think it wrong to focus solely on HTTP; if that is wanted, then this is
RFC2818bis. HTTP is a special case, big fat server, human sitting at workstation
ready to deal with difficult cases, quite unlike the uses to which TLS is now
put, such as the ones I mention above.

Tom Petch

>  In practice, in the HTTP world,

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Jun 2009 12:46:09 -0500

> and we have to start all over again:---(

The oddities in cert naming arise mostly from the world of the web.  I
suppose that such oddities show up in other contexts simply because the
same CAs are involved.  If so, then I'd sadly agree that you need this
doc to apply in those non-web cases too.

> I was sloppy in saying certificates, I did mean X.509 and not PGP etc,
> but want to include the non-PKI case, eg fingerprints.  PKI is a
> hassle which is why I see it as a great invention, technically
> brilliant, but one that may or may not take off, one day (IPv6, OSI,
> Token Ring, ....). So giving users the option of X.509 with
> fingerprints just may allow them to introduce security when X.509 with
> PKI would put them off.  I am a great believer in 'better something
> than nothing', fearing that the IETF sets the bar at a level when
> users opt for nothing instead.

"X.509 with fingerprints" meaning SSH-style leap-of-faith?  Fine.  Of
course, if you have anything better to go on you can always use channel
binding to "learn" the cert (much like SSH clients using the GSS-API-
based SSHv2 key exchange learn server host keys).

> I think it wrong to focus solely on HTTP; if that is wanted, then this
> is RFC2818bis. HTTP is a special case, big fat server, human sitting
> at workstation ready to deal with difficult cases, quite unlike the
> uses to which TLS is now put, such as the ones I mention above.

Fair enough, but it is worth pointing out the origins of certain
practices.

Nico
--

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Jun 2009 14:14:52 -0400

Hi,

I think it is important to understand that syslog/tls and netconf/tls
and snmp/tls have specific needs that are not necessarily present in
the common HTTP use case.

Network management needs to work in flaky networks. HTTP/tls normally
does not need to deal with this issue; you just get a 404 error or
something in response, or a browser prompts a user for "what do I do
now?".

IETF standard network management protocols usually require that the
protocol should NOT be dependent on third party services to operate.
That is, the protocols need to work even if PKI or AAA or other
third-party service is not available via the network.

As Tom points out, syslog and netconf have been designed to use
fingerprints to deal with this situation. It would be good if this
approach was written down and standardized so this solution can be
reused by all IETF applications that need to meet this requirement.

It is also important to understand that the nature of "Internet
management" is changing. Ten years ago, we didn't have syslog or
netconf or ipfix in the IETF standard management protocol stable; we
had SNMP as the one-and-only be-all management protocol. To better
accommodate the changing nature of the Internet, we are changing IETF
requirements for operations and management, and allowing new
management protocols to be designed for specific purposes. It would be
a good thing for operators if we used a standardized approach for
securing emerging management protocols with TLS.   

This is a particular use case, but one that exists for a growing
number of management protocols, so a separate document describing a
standard for "certificates without PKI" could be appropriate.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Monday, June 08, 2009 12:34 PM
> To: Nicolas Williams
> Cc: [email-masked]; Apps Discuss

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Jun 2009 12:31:26 -0600

On Jun 5, 2009, at 9:14 AM, Kurt Zeilenga wrote:

> methods.   However, as not every way to verify the TLS server  
> identity is applicable to every application protocol which uses TLS,  
> I do not think it feasible to develop a "generic" procedure (as the  
> previous title suggested).
>
> TLS server identity verification to be done and be organized such  
> that application protocol specifications can easily "profile" this  
> document in order to specify the application protocol specific  
> procedure.  I think the document should be targeted for the Standard  
> Track.
>
> identity verification with X.509 certificates.  I don't mind having  
> a title which indicates this narrow focus, but am also fine with a  
> title which leaves the "with X.509 certificates" aspect implicit.
>
> -- Kurt

I would like to +1 what Kurt said.

Specifically, saying this is a BCP to which all existing protocols  
need to conform is just not going to fly. However, having one "cook  
book" Standards Track RFC that all new things can point at and say,  
just do it like RFC AAAA says to do it would be great.

I think it might be good to consider the wildcard issue a bit deeper  
too. It might be good good for the cookbook to have two things  
specified, ones that allows wildcard and one that does not.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Jun 2009 18:43:05 +0100

> specified, ones that allows wildcard and one that does not.

+1.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 12 Jun 2009 15:35:19 +0200

----- Original Message -----
From: "Alexey Melnikov" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 10, 2009 7:43 PM
Subject: Re: TLS server identity verification

> > specified, ones that allows wildcard and one that does not.

The most recent treatment I have seen is in RFC5425 s5.2.

Note that when wildcards are allowed, then they have two uses, one in the
dNSName, the other in the reference identity. I would like to see both covered.

I like the idea of a cookbook because that to me includes a variety of
approaches, from which a user can select a menu appropriate to their
situation, such as section 3.1A and 4.2C.

Tom Petch