Subject: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The Transport Layer Security (TLS) Protocol Version 1.2) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 13 Feb 2008 07:15:41 -0800 (PST)

The IESG has received a request from the Transport Layer Security WG 
(tls) to consider the following document:

- 'The Transport Layer Security (TLS) Protocol Version 1.2 '
   <draft-ietf-tls-rfc4346-bis-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-02-27. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14466&rfc_flag=0

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

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 28 Feb 2008 14:57:23 -0600

TLS Supplemental Data [RFC4680] was overlooked, e.g. in section 7.4.2.
Server Certificate,

      The server MUST send a certificate whenever the agreed-upon key
      exchange method uses certificates for authentication (this
      includes all key exchange methods defined in this document except
      DH_anon).  This message will always immediately follow the server
                                   ^--No
      hello message.

Also in section 7.4.7. Client Key Exchange Message,

      This message is always sent by the client. It MUST immediately
                                                    ^--No
      follow the client certificate message, if it is sent. Otherwise it
      MUST be the first message sent by the client after it receives the
      ^--No
      server hello done message.

Instead, per [RFC4680], ServerCertificate may follow a server's
SupplementalData message.  Also, Client Key Exchange follows the client
Certificate message and/or the client SupplementalData message, if these
messages are sent.  

[RFC4680] should also be added to the references section.  It may be helpful
to add SupplementalData to Figure 1 on page 34 of rfc4346-bis as well,
marked with an asterisk *, following Figure 1 in [RFC4680].

--mark

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

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 13:29:24 +0200

I wouldn't say it was overlooked; it's simply not in scope of
this document. There are other documents that define new TLS 
handshake messages (at least RFC 4366(bis) and RFC 5077
in addition to RFC 4680), and those messages are not mentioned 
here either (and don't have to be).

Best regards,
Pasi 

> -----Original Message-----
> From: Mark Brown
> Sent: 28 February, 2008 22:57
> To: [email-masked]
> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The 
> TransportLayer Security (TLS) Protocol Version 1.2) to 
> Proposed Standard
>

---

From: "Mark Brown" <[email-masked]>
Date: Fri, 29 Feb 2008 10:38:02 -0600

Ok, thanks.  

So, my understanding is that TLS Supplemental Data [RFC4680] is Ok &
Standard to use even though it violates the prohibitions below.  Is that
right?  (Neither 4366-bis nor 5077 violate prohibitions...)

--mark

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 29, 2008 5:29 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
> TransportLayer Security (TLS) Protocol Version 1.2) to Proposed Standard
> 
>