Subject: [TLS] draft-ietf-tls-oob-pubkey-06

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 03 Nov 2012 00:20:27 +0100

Hello,
 I've read the new draft "Out-of-Band Public Key Validation for
Transport Layer Security", and I was surprised by the approach chosen to
define the new certificate type for TLS.

Some background. There is already a certificate type extension in TLS,
called "cert_type" defined in the RFC6091. The exact extension is copied
in the "draft-ietf-tls-oob-pubkey-06" document, with a different name
(called "certificate_type"), and different and incompatible certificate
type assignment values. Even more it does not define the any old types
from RFC6091 meaning that somebody in order to support RFC6091 and
draft-ietf-tls-oob-pubkey-06 MUST support two different certificate type
extensions. In the text there is no reasoning on the need of the new
extension and even the reference to RFC6091 was removed (I couldn't find
a discussion on the ML either).

I don't want to think what it is going to happen when we have a 3rd
certificate type to be defined for TLS. Do we really need a different
extension for every possible certificate type? Can't we fix a single
certificate type extension that will be used for all possible
certificate types? As an implementer I'd like to support both openpgp
and SubjectPublicKeyInfo types but the current approach chosen is really
unacceptable.

regards,
Nikos

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 3 Nov 2012 17:59:55 +0200

Hi Nikos, 

around the last IETF meeting I got feedback from the working group about avoiding a normative reference to RFC 6091. 
The current document version avoids that dependency.

I didn't see the need to add OpenPGP support in this document. 

Ciao
Hannes

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 3 Nov 2012 11:13:37 -0700

> I didn't see the need to add OpenPGP support in this document. 

+1 to both statements.

--Paul Hoffman

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 03 Nov 2012 19:30:13 +0100

> The current document version avoids that dependency.

Hello,
 May I ask what were the arguments for that, or it is a secret?

> I didn't see the need to add OpenPGP support in this document. 

So the idea is to have multiple certificate type extensions for TLS?
This was the meeting consensus?

Why wasn't this brought up to the mailing list given that this overrides
the previous consensus [0] on the mailing list?

regards,
Nikos

[0]. http://www.ietf.org/mail-archive/web/tls/current/msg08290.html

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 3 Nov 2012 14:58:26 -0400

Hi Nikos, 

thanks for the quick response. 

> May I ask what were the arguments for that, or it is a secret?

I unfortunately missed the meeting last time so I am probably not the best person to reflect the discussion from the meeting myself.
RFC 6091is an informational RFC and would require to be upgraded to a standards track document or a downref needs to be specified in the tls-oob-pubkey document. 

Dealing with such a downref to RFC 6091 would be useful if RFC 6091 would actually be a good fit. There are two problems:

1. OpenPGP support in TLS is IMHO not deployed.  
2. A problem I noticed with re-using RFC 6091 is that the certificate capability indication does not allow a client to distinguish whether it supports processing of OpenPGP certificates vs. whether it is able to provide OpenPGP certificates. For this reason the structure is different in draft-ietf-tls-oob-pubkey.

> This was the meeting consensus?
Luckily there are not that many certificate formats. If someone would want to define a new extension then they should be using draft-ietf-tls-oob-pubkey.

> the previous consensus [0] on the mailing list?
I am not the chair of the group. I let them to judge consensus in the way they want. 

Ciao
Hannes

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 04 Nov 2012 11:55:36 +0100

> 1. OpenPGP support in TLS is IMHO not deployed.  

Hello,
 I've never done a survey on the deployment, but I trust your research.

> Luckily there are not that many certificate formats. If someone would want to define a new extension then they should be using draft-ietf-tls-oob-pubkey.

Shouldn't in that case the oob-pubkey draft obsolete or update rfc6091?
I don't think that both the certificate type registries should be active.

> I am not the chair of the group. I let them to judge consensus in the way they want. 

This was not a question for you.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 06 Nov 2012 16:07:48 +0100

> I didn't see the need to add OpenPGP support in this document.

If the meeting that you mean is IETF-84 then my reading of the minutes
[0] is different. There is no suggestion to create a new certificate
type anywhere. My reading is that the suggestion is to use the existing
type by copying it to the new draft.

In any case, even if your belief is correct that the OpenPGP type has to
be deprecated, I think that intentionally creating conflicting
extensions is bad practice.

[0]. http://tools.ietf.org/wg/tls/minutes?item=minutes-84-tls.html

regards,
Nikos

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 06 Nov 2012 16:33:15 +0100

Hi (Hannes),

- Is there a need to make a normative reference to  6091.
If the definition is completely make in a compatible way,
an informative reference is sufficient IMO.

- What does is the problem to make the definitions compatible
   i.e. define a value for pgp?

- Besides that, a public key is not exactly a "certificate" type?

- How would one add a sunrise hash chain as a new certificate type?

peter

On 11/06/2012 04:07 PM, Nikos Mavrogiannopoulos wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Peter Sylvester

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Nov 2012 10:53:02 -0500

Hi Peter, 

thanks for your comments. 

> an informative reference is sufficient IMO.

The current version of the document does not make any reference to RFC 6091. 

A normative reference is required when we use functionality from RFC 6091, such as the cert_type parameter and the registry. 

>   i.e. define a value for pgp?

There is no problem to add a value for OpenPGP if there is interest in doing so. 
The question for me is: 
 * Who cares about client authentication using OpenPGP? 
 * Who cares about server authentication using OpenPGP?

> - Besides that, a public key is not exactly a "certificate" type?
I am happy to change the name. In any case the idea is to put the SubjectPublicKeyInfo into the certificate payload. 
So, using certificate_type does not seem too far fetched. 

> - How would one add a sunrise hash chain as a new certificate type?

Not sure I understand what you would like to do. 

Ciao
Hannes

>> [0]. 
>> http://tools.ietf.org/wg/tls/minutes?item=minutes-84-tls.html
>> 
>> 
>> regards,
>> Nikos

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Nov 2012 10:55:22 -0500 (EST)

>  i.e. define a value for pgp?

I believe the problem was that 6091 was not a standards track document.

> - Besides that, a public key is not exactly a "certificate" type?

It is how the TLS WG preferred the raw public key format to be
supported.

> - How would one add a sunrise hash chain as a new certificate type?

One would not. If the rae public key certificate format does not satisfy
your needs, use the existing PKIX certificate, or create a new
certificate type?

Paul

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 06 Nov 2012 17:34:27 +0100

> The current version of the document does not make any reference to RFC 6091.
RFC  6091 has

     enum { client, server } ClientOrServerExtension;

       enum { X.509(0), OpenPGP(1), (255) } CertificateType;

       struct {
          select(ClientOrServerExtension) {
             case client:
                CertificateType certificate_types<1..2^8-1>;
             case server:
                CertificateType certificate_type;
          }
       } CertificateTypeExtension;

ietf-tls-oob-pubkey has

enum { client, server } ClientOrServerExtension;

    enum { X.509-Accept (0),
           X.509-Offer (1),
           RawPublicKey-Accept (2),
           RawPublicKey-Offer (3),
           (255)
          } CertificateType;

    struct {
       select(ClientOrServerExtension)
           case client:
             CertificateType certificate_types<1..2^8-1>;
           case server:
             CertificateType certificate_type;
       }
    } CertTypeExtension;

I find this rather unfortunate not to share the same extension.

> A normative reference is required when we use functionality from RFC 6091, such as the cert_type parameter and the registry.

rfc4897 says you can as far as I see:

       A note is included in the reference text that indicates that the
       reference is to a target document of a lower maturity level, that
       some caution should be used since it may be less stable than the
       document from which it is being referenced, and, optionally,
       explaining why the downward reference is appropriate.

>   * Who cares about server authentication using OpenPGP?
Why do you care?

One could use any other number the 0 and 1 for the first options?

> So, using certificate_type does not seem too far fetched.
IMO it may be the contrary:  An info has nothing to do how it is 
'certified' or 'asserted' or whether.
The whole thing could be called KeyInfo or something.
The title of the document indicate 'oob'.

> Not sure I understand what you would like to do.
oops, sunlight, not sunrise

http://tools.ietf.org/html/draft-laurie-pki-sunlight-00

Tschö
Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Nov 2012 11:53:33 -0500

Hi Peter, 

while the approach taken by RFC 6091 and by draft-ietf-tls-oob-pubkey-06 look similar the semantic is actually different. 
The difference between the two approaches is that draft-ietf-tls-oob-pubkey-06 allows you to pick different certificate types for the client and the server whereas RFC 6091 does not seem to have such a provision. 

I am aware of RFC 4897. I know that a downref is possible and till version -03 I had envisioned that the approach we would be using. I then realized that the semantic is different. 

Regarding the support of OpenPGP I am not against adding the support for it but I would like to understand whether there is a chance that someone implements and deploys it. I don't think we should just add functionality because it is theoretically possible. 

KeyInfo sounds good to me. 

I will take a look at draft-laurie-pki-sunlight-00

Ciao
Hannes

On Nov 6, 2012, at 11:34 AM, Peter Sylvester wrote:

> IMO it may be the contrary:  An info has nothing to do how it is 'certified' or 'asserted' or whether.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 06 Nov 2012 18:19:00 +0100

On 11/06/2012 05:53 PM, Hannes Tschofenig wrote:

> while the approach taken by RFC 6091 and by
> draft-ietf-tls-oob-pubkey-06 look similar the semantic is actually
> different. The difference between the two approaches is that
> draft-ietf-tls-oob-pubkey-06 allows you to pick different certificate
> types for the client and the server whereas RFC 6091 does not seem to
> have such a provision. I am aware of RFC 4897. I know that a downref
> is possible and till version -03 I had envisioned that the approach
> we would be using. I then realized that the semantic is different.

The semantic difference may or may not require to break backwards
compatibility.

> Regarding the support of OpenPGP I am not against adding the support
> for it but I would like to understand whether there is a chance that
> someone implements and deploys it. I don't think we should just add
> functionality because it is theoretically possible.

Do you really have that assurance of the SubjectPublicKeyInfo extension?
In any case TLS with openpgp is implemented and deployed. There is even
an apache module supporting it.

regards,
Nikos

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Nov 2012 12:27:32 -0500

Hi Nikos, 

> The semantic difference may or may not require to break backwards

How was RFC 6091 supposed to be used? Was the expectation that the server provides a PGP certificate? 

> an apache module supporting it.
Good to hear.

So, what prevents those people just continuing to use RFC 6091? 

Ciao
Hannes

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 07 Nov 2012 11:42:19 -0400

It was quite a while since I wrote the first version of this draft.
Now that I bring it up to my attention I found a problem that I think
should be fixed.

After a close examination I'm convinced that the current spec breaks TLS.

The current approach is to exchange support for cached-info in client and
server hellos.
This includes hashes for cached objects (clients) and confirmation of
cached objects (server).

In addition to this, this protocol allows the cached data in handshake
messages to be swapped with cached object hashes.
This is a violation of the syntax of these handshake messages.

Take the Certificate handshake message for example. The spec suggest here
to replace the certificate_list vector to be replaced with a vector of
CachedObejct structured data.
This breaks the syntax of this handshake message. A strict processing of
the certificate_list vector will expect an ASN.1 encoded binary containing
a sequence of certificates, not a vector of data objects according to the
CachedObject structure.

My first thought was that we actually need a new handshake message.
However that is not helpful either.
The TLS spec require the Certificate handshake message to be sent in case
the chosen cipher suite demands it, so it MUST be sent.
It can't be replaced by another handshake message.

My current belief is that we simply should omit the cached data, and that
each cachedInfo type need to defined how to omit cached data.

In case of the certificate handshake message, the certificate list should
be replaced with an empty sequence.

There is actually no need to send the hash of the cached data in the
handshake message. Not if the confirmation of the cached info is exchanged
in the server hello. Sending the hash once more in the handshake message
is then redundant.

So I propose the following:

1) Clients send hashes of cached objects in client hello.
2) Server responds with one or zero hashes per cachedInfo type, that a)
matches a cached object sent by the client b) will be omitted by the
server in the corresponding handshake message.
3) How information is omitted from the handshake message is defined per
cached info type. For the current defined 2 types this is:
  A) cached certificate cahins in Certificate: replace the sequence of
certificates with an empty sequence.
  B) certificate_authorities in Certificate Request: Send an empty list of
DistinguishedName
4) Clients will act as if the cached objects (confirmed in server hello)
were sent in the handshake messages.
5) Everything else according to the current spec

The proposed approach will somewhat limit the functionality of the current
spec, but it ads value in simplicity.
I can't imagine a valid use case that would not be covered by this change,
but I might overlook something.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 28 Nov 2012 05:19:04 +0000

Hi Stefan,

This new proposal of omitting the data sounds a bit simpler to me.   You say the new approach will limit the functionality in some way.  In what way is it limited?  

Do you think we could accommodate the case where the endpoint has intermediate CA certificates cached but not the end entity certificate? This would require parsing the certificate message, but the response could just omit the certs that were indicated in the cachedInfo.   The parsing of the cert message is a bit more complex, but it could satisfy some of the use cases discussed at the meeting.

Thanks,

Joe