Subject: [apps-discuss] [APPS-REVIEW]Review of draft-mavrogiannopoulos-rfc5081bis

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Sep 2010 14:54:24 -0700

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-mavrogiannopoulos-rfc5081bis
Reviewer: Ted Hardie
Review Date: September 15th, 2010
On agenda of 2010-09-23 IESG telechat

Summary: This draft is almost ready for publication, but there remain
a few issues which need clarification in the text.

Major Issues:

The introduction to the document says:

"The proposed extensions are backward compatible with the current TLS
   specification, so that existing client and server implementations
   that make use of X.509 certificates are not affected."

but the Appendix, which describes the changes from RFC 5081,  notes that
there is a major and incompatible change:

   This document incorporates a major and incompatible change in the
   "Server Certificate" and "Client Certificate" TLS messages.  This
   change requires the subkey IDs used for TLS authentication to marked
   explicitely in the handshake procedure.  This was decided in order to
   place no limitation on the OpenPGP certificates' contents that can be
   used with with this protocol.

   [RFC5081] required that an OpenPGP key or subkey was marked with the
   authentication flag and thus would have failed if this flag was not
   set, or this flag was set in more than one subkeys.  The protocol in
   this memo has no such limitation.

Section 3 indicates that the presence of the "cert_type" extension signals
the ability to handle the new handshake procedure; it also, unfortunately,
contains some language which appears contradictory.  In section 3.2,
it says:

   If the server receives a client hello that contains the "cert_type"
   extension and chooses a cipher suite that requires a certificate,
   then two outcomes are possible.  The server MUST either select a
   certificate type from the certificate_types field in the extended
   client hello or terminate the session with a fatal alert of type
   "unsupported_certificate".

It goes on to say, however:

  It is perfectly legal for a server to ignore this message.  In that
   case the normal TLS handshake should be used and, other certificate
   types than the default MUST NOT be used.

The combination of these issues leaves potential confusion about how compatible
this mechanism is with previously defined behavior and how mandatory support
is.  Reading through it, the intent appears to be:

Use the "cert_type" extension mechanism to signal support for a
non-compatible handshake mechanism.
   If the client and server support the "cert_type" extension, the
spec requires that servers either select
    a certificate type from the certificate_types field or fail.
Servers remain free not to support the extension at all.

Some language clean-up to make this clear seems to me required.  I
would personally
probably integrate the appendix material into the introduction.  I
would also suggest
clarifying in Section 3 which statements apply to the negotiation after it has
been established that "cert_type" is supported by both parties.

Minor Issues:

The IANA section should probably note that the pointer for the "cert_type"
TLS extension should be updated to this document.

Nits:

---

From: nikos <[email-masked]>
Date: Thu, 16 Sep 2010 10:51:26 +0200

> On agenda of 2010-09-23 IESG telechat

Hello,
 Thank you for the comments. I have some clarifications for the text and 
some proposed changes, inline.

>    this memo has no such limitation.

Please note that those two paragraphs refer to different documents.
The phrase "The proposed extensions are backward compatible with the 
current TLS specification" (RFC5246) and the appendix refers to 
experimental RFC5081 from which there are incompatible changes. If it is 
ok with you after this clarification, I'll leave this text as is.

>    types than the default MUST NOT be used.

You are right here also on the intention of the text. Would removing the 
paragraph:
   "It is perfectly legal for a server to ignore this message.  In that
   case the normal TLS handshake should be used and, other certificate
   types than the default MUST NOT be used."
make the text more clear for you?

This paragraph was intended as a clarification on the last sentence of 
the previous paragraph:
"Servers that only support X.509 certificates MAY omit including the
"cert_type" extension in the extended server hello."
but might be misunderstood, thus removing it should resolve that issue.

> been established that "cert_type" is supported by both parties.

The text has been based on RFC2246-RFC5246 structure of describing the 
handshake procedure and it lists the handshake messages that change for 
this method. I believe all statements in section 3 apply to the 
handshake procedure. If something is not clear please let me know.

> TLS extension should be updated to this document.

Would this change
"This document uses a registry and the "cert_type" extension originally 
defined inRFC5081. Existing IANA references should be updated to
point to this document."
be ok with you?

best regards,
Nikos

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Sep 2010 09:41:05 -0700

Hi Nikos,

Thanks for the quick reply, some comments in-line.

> ok with you after this clarification, I'll leave this text as is.

The final decision is, of course, up to the iesg.  My personal take is that
"backwards compatible" is liable to cause confusion in this context.  It uses
the current extensions mechanism and thus has the current framework's
ability to detect when an extension is not supported.  But the current text
seems to be trying a bit too hard to say "Don't worry, X509 users, this won't
hurt a bit."  May I suggest:

"The proposed extensions are signaled within the current extensions
framework[TLS],
so that existing client and server implementations that support only
X.509 certificates
and do not support this extension will not be affected."

I'd also suggest adding an explicit citation to the Appendix, noting
that it is not
backwards compatible with 5081, but it is a standard extension to  TLS
as set out
in RFC 5246.

are backward compatible with the current
>> TLS

> make the text more clear for you?

Yes, I think that would remove the ambiguity, as it leaves the
standard extension
processing understood.

> defined inRFC5081. Existing IANA references should be updated to

Yes, that sounds fine.

Thanks again for your response,

Ted

---

From: nikos <[email-masked]>
Date: Thu, 16 Sep 2010 19:56:05 +0200

Hello,

 (comments inline)

Quoting Ted Hardie <[email-masked]>:
> hurt a bit."  

I think that the introduction serves its purpose, but I can see that the 
appendix could be misleading if read out of context. I've updated the 
appendix to make clear that the incompatibility is with RFC5081 and not 
with other documents:
   "This document incorporates a major change in the "Server 
Certificate"
   and "Client Certificate" TLS messages, that will make implementations
   following this protocol incompatible with ones following [RFC5081].
   This change requires the subkey IDs used for TLS authentication to
   marked explicitely in the handshake procedure.  This was decided in
   order to place no limitation on the OpenPGP certificates' contents
   that can be used with with this protocol."

I've uploaded a -07 version with the fixes discussed.

Thank you and best regards,
Nikos