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

From: <[email-masked]>
Date: Wed, 10 May 2006 20:21:46 +0300

The document looks mostly OK, but I think some details need 
clarification/polishing before we send this to the IESG.

Somewhat substantive comments:

1) Section 3.3: The TLS Certificate message defined in RFC4346 
   contains a list of X.509 certificates, while this section allows
   only a single PGPKey structure. IMHO we should keep this aligned
   with RFC4346, even though usually one key is enough. In other 
   words, something like this:

      struct {
          PGPKeyDescriptorType descriptorType;
          select (descriptorType) {
              case key_fingerprint: opaque fingerprint<16..20>; 
              case key:             opaque key<0..2^24-1>; 
          }
      } PGPCert;

      struct {
          PGPCert certificate_list<0..2^24-1>;
      } Certificate;

2) Section 3.5: "then a Certificate that contains an empty PGPKey
   should be sent": If the change suggested above is made, a 
   Certificate message that contains one zero-length PGPKey is 
   not the same thing as a Certificate message that contains zero 
   certificates (and it's the latter that should be sent).

3) Section 3.4: I don't think there is any need to define a new
   CertificateRequest message (the "certificate_authorities" part
   doesn't make much sense for OpenPGP, but RFC4346 clarified that
   it can be empty; and I believe many TLS 1.0 implementations also
   did this). So I'd suggest rewriting this section as follows:

   "If the certificate request message is sent, and the negotiated
   certificate type is OpenPGP, the certificate_authorities list 
   MUST be empty."

4) I'd suggest moving whole Section 2 to later in the document 
   (e.g., after Security Considerations), renaming it to "IANA
   Considerations", and rewriting it something like this:

   "This document defines a new TLS extension, "cert_type", assigned
   a value of TBD-BY-IANA (the value 7 is suggested) from the TLS
   ExtensionType registry defined in [RFC4366].
  
   This document establishes a new registry, to be maintained by
   IANA, for TLS certificate types. Initially, the registry contains
   the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223
   are assigned via IETF Consensus [RFC2434]. Values from the range
   224-255 are reserved for Private Use [RFC2434]."

5) Section 3.1: "...extension SHOULD be omitted if the client only
   supports X.509 certificates" and "Servers that only support X.509
   certificates MAY omit... ": Unnecessary options are a recipe for
   interoperability problems; unless there are good reasons to keep
   these, I'd suggest changing these to MUSTs.

6) Section 4: I'd suggest merging this section (only four lines)
   with Section 3.1. Also, the text should apply to all ciphersuites
   using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just
   those in RFC 2246. (And with this change, the text about
   exportable ciphersuites is no longer necessary.)

Purely editorial comments:

7) Overall: I believe nowadays the RFC Editor recommends using 
   symbolic citations [RFC2119] instead of numeric ones [1].

8) Section 1, 2nd paragraph: extra comma before "provide"

9) Sections 3.6..3.8: I'd suggest removing these.  

10) Section 3.3: "The process of fingerprint generation is described 
   in OpenPGP [2]": I'd suggest adding a more specific pointer:
   Section 11.2 of [RFC2440].

11) Section 6.1: RFC 3546 is obsoleted by RFC 4366.

12) Section 6.1: Should include RFC 2119 and RFC 2434 here.

13) Section 6.2: Reference [5] is never cited in the text (and
   IMHO could be removed)

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 11 May 2006 16:42:56 +0200

On 5/10/06, [email-masked] <[email-masked]> wrote:

Hello Pasi,
 Thank you for the comments. I address them below.

>    only a single PGPKey structure. IMHO we should keep this aligned

This was a deliberate change. The rationale behind this change was
that there is no point in sending more than one pgp keys. There is no
notion of certificate chain in openpgp, thus having a list of 
certificates would
confuse on what should be sent.

>    certificate type is OpenPGP, the certificate_authorities list

I will address this.

>    224-255 are reserved for Private Use [RFC2434]."

Will be addressed.
(I just noticed that in http://www.iana.org/numbers.html there is 
nothing
about the TLS extension numbers. Is restristration possible?)

>    these, I'd suggest changing these to MUSTs.

I agree for the first one. But the second is only to address the case 
where
the server doesn't support this extension (thus he doesn't add the
extension reply
to his hello). But I'd expect a server that is aware of this extension
to properly
reply with an extension that indicates that he selected the X509
certificate choice.

>    exportable ciphersuites is no longer necessary.)

True. I'll update it.

> 13) Section 6.2: Reference [5] is never cited in the text (and

Thanks I'll try to address the comments in a new draft.

---

From: <[email-masked]>
Date: Tue, 16 May 2006 10:14:47 +0300

Nikos Mavrogiannopoulos wrote:

> certificates would confuse on what should be sent.

If Alice signs (certifies) Bob's key, and Bob signs Carol's key,
isn't that a certificate chain? (The whole notion of "web of trust"
seems to imply a certificate graph, which again implies chains...)

> nothing about the TLS extension numbers. Is restristration possible?)

For some reason, the index page doesn't have a link to the registry
(I'll notify IANA about this), but the registry is there:

http://www.iana.org/assignments/tls-extensiontype-values

> where the server doesn't support this extension (thus he doesn't add 
> the extension reply to his hello). But I'd expect a server that is 
> aware of this extension to properly reply with an extension that 
> indicates that he selected the X509 certificate choice.

Sounds reasonable to me.

Best regards,
Pasi

---

From: "Nikos Mavrogiannopoulos" <[email-masked]>
Date: Tue, 16 May 2006 11:35:22 +0200

> seems to imply a certificate graph, which again implies chains...)

Indeed that's true.But it is also not very practical to include
signers in the key sent.
That is because a key might be signed by tens or hundrends of keys, that are not
compact either. I also see not much usage of the extra keys. The
typical way for the receipient to verify an openpgp key is by
retrieving by himself the required chain, if needed.

A similar matter was discussed in the early days of the draft... i
just found a link:
http://www.mhonarc.org/archive/html/ietf-openpgp/1997-12/msg00105.html

regards,
Nikos

---

From: <[email-masked]>
Date: Tue, 16 May 2006 12:47:19 +0300

Nikos Mavrogiannopoulos wrote:
> signers in the key sent. That is because a key might be signed by
> tens or hundrends of keys, that are not compact either. I also see
> not much usage of the extra keys. The typical way for the receipient
> to verify an openpgp key is by retrieving by himself the required
> chain, if needed.

All this ("typical way" etc, "might be signed by tens", ..) seems to
indicate that usually a single certificate is enough, but there may
be situations where several would be useful. In other words, the 
situation is not that different from X.509, and we should keep the 
Certificate payload as a list...

> A similar matter was discussed in the early days of the draft... 
> i just found a link:

Thanks for the pointer; it looks like Eric raised exactly this issue
already over 8 years ago!

Best regards,
Pasi

---

From: "Nikos Mavrogiannopoulos" <[email-masked]>
Date: Tue, 16 May 2006 12:17:51 +0200

> Certificate payload as a list...

Indeed there are situations were a list might do, but there are also situations
where a graph would be better, or just a single one might do. The idea in this
draft is to keep the key exchange separate from any local verification policy.
If one wants to use the web of trust, he can use it. If somebody else
wants to use
openpgp keys the same way as PKIX certificates, he can also use the
current draft.
In all cases unknown keys are retrieved via a key server or by other means.

That approach follows the way openpgp keys are used in electronic mail
and I see no good reason to change it by introducing an openpgp key
chain in this draft.

regards,
Nikos

---

From: <[email-masked]>
Date: Tue, 16 May 2006 14:59:38 +0300

Nikos Mavrogiannopoulos wrote:

> Indeed there are situations were a list might do, but there are also
> situations where a graph would be better, or just a single one might
> do.  The idea in this draft is to keep the key exchange separate
> from any local verification policy.  If one wants to use the web of
> trust, he can use it. If somebody else wants to use openpgp keys the
> same way as PKIX certificates, he can also use the current draft.

This argument would also suggest that the ability to send multiple
X.509 certificates is unnecessary, since all the other certs could
(in theory at least) be retrieved from directory servers. 

You can't use this draft "the same way as PKIX certificates" unless
you have the key server or "other means" working in practice. In 
current uses of TLS with X.509 certificates, this infrastructure 
is not necessarily present, and the ability to send several 
certificates is used.

Thus, I would not hard-code this limitation in the specification,
especially when it's very easy to avoid (just allow a list just
as in normal TLS), and there's just 3 bytes of overhead for 
implementations that send only one PGP key... (and in fact
even this overhead could be avoided if we remove the redundant
length field by stating that the "key descriptor type" is the
first byte of the key data)

> and I see no good reason to change it by introducing an openpgp key

It does not follow the email way of using PGP: most email messages
don't contain the public key at all (only the signature), and when 
the public key is included, a single message can contain several 
keys (see e.g. RFC 3156 Section 7), presumably forming some kind of 
graph (not necessarily a single chain).

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 May 2006 15:53:39 +0200

<[email-masked]> writes:

> you have the key server or "other means" working in practice.

I believe PGP key servers are working in practice.

> In current uses of TLS with X.509 certificates, this infrastructure

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 agree that limiting the protocol to carry one key is a theoretic
limitation, although I don't see anyone describing a practical
scenario where this limitation is critical.

Regards,
Simon

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2006 07:50:15 -0700

> 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". 

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 16 May 2006 19:07:51 +0200

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.

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.

regards,
Nikos

[0]. the PGPKeyDescriptorType allows for extra functionality such as 
key_lists(2) to be added if needed.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 16 May 2006 19:32:41 +0200

> first byte of the key data)

It is not about the byte overhead. It is about defining what a key chain
is how is it going to be used, what is an implementor going to put there 
etc. Otherwise it would be a pandoras box, waiting to be opened. 

Given the feedback I've got all the years this draft exists, it seems 
that nobody so far had a need for it. If in the future this proves to 
be a limitation, it is easy to add an extra key descriptor type with a 
key list, that follows some rules, or none. 

> > That approach follows the way openpgp keys are used in electronic
> > mail and I see no good reason to change it by introducing an
> > openpgp key chain in this draft.

+ the fingerprint of the signer, because that's what is needed for 
authentication. The receipient is responsible for retrieving the
keys based on the fingerprint. 

regards,
Nikos

ps. I hope I didn't get rude or personal in this or previous mails, but 
my point is that since we have no use of this functionality today, I 
see no point in adding it. If needed it might be better to be added 
from people who would use it because they will define it the way the 
really need it.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 16 May 2006 16:57:36 -0400

> 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.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2006 14:03:45 -0700

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 May 2006 11:47:52 +0200

> the trust graph from giving hints.

I believe that protocol fields with undocumented semantics, and where
the algorithms that make use of those fields are not documented [1],
leads to poor interoperability.

As Nikos said, if someone wants this, it is easy to extend the
PGPKeyDescriptorType enum to add a key_list(2), and then describe the
semantics related to it.  If someone volunteers to write that, we
could review that text to see if it seems correct, but, IMHO, the onus
to write this should be on those who proposed this change in the
document.

Regards,
Simon

[1] I'm guessing here.  If what PGP does is documented and part of
some standard, the situation would be different.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 May 2006 08:22:29 -0700

> leads to poor interoperability.

It's not undocumented. It's "add these certs to your bucket of certs"
and use them in whatever resolution mechanism you have.

> to write this should be on those who proposed this change in the

I don't agree that this should be an extension, but I am willing
to go along with the burden of work argument. Pasi, you want to
contribute text?

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 May 2006 18:28:57 +0200

> and use them in whatever resolution mechanism you have.

How are clients and servers, respectively, supposed to figure out
which keys to include?

Presumably, they should not send their entire key ring, right?  Some
properties of the resolution algorithms appear to be needed to pick
the "appropriate" keys, and limit the set of keys to send.

Compare RFC 4346, which says on X.509 certs:

   certificate_list
      This is a sequence (chain) of X.509v3 certificates.  The sender's
      certificate must come first in the list.  Each following
      certificate must directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority may optionally be omitted from the chain,
      under the assumption that the remote end must already possess it
      in order to validate it in any case.

What I'm looking for are similar guidelines to decide which OpenPGP
keys to include, but I'm skeptical about the existence of useful such
guidelines.

Regards,
Simon

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 May 2006 09:31:41 -0700

> keys to include, but I'm skeptical about the existence of useful such

Rather than arguing about whether such rules are possible (though 
I think they are in practice), why don't we see if Pasi wants to
try to write something?

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 May 2006 18:58:02 +0200

> I think they are in practice), why don't we see if Pasi wants to

Yup, agreed.

/Simon

---

From: <[email-masked]>
Date: Thu, 18 May 2006 10:30:54 +0300

> I think they are in practice), why don't we see if Pasi wants to

As far as I know, there is no RFC that really describes how PGP key
validation works (RFC 2440 describes the on-the-wire formats, but not
much more). Thus, even the current version of
draft-ietf-tls-openpgp-keys 
can't do any better than saying "The key validation procedure is a 
local matter outside the scope of this document".

So if we're really worrying about unspecified semantics, that's
certainly one huge missing part...

If the key validation rules would be described somewhere, I think
handling multiple keys/certificates could be as simple as saying "the 
sender MAY include additional keys/certificates it believes to be useful

to the recipient (how this is determined is a matter of local policy and
configuration)" and "the recipient incorporates all the received
keys/certificates (not just the first one) in the key validation
procedure".

Best regards,
Pasi