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

[Simon Josefsson <simon at josefsson.org>]

TLS versioning and IETF update/obsolete-versioning has different
semantics.  RFC 4680 updates RFC 4346, i.e. TLS 1.1.  If RFC 4346 is
obsoleted by RFC 4346bis (TLS 1.2), then RFC 4680 will not automatically
update RFC 4346bis.  My interpretation is that RFC 4680 will have to be
revised to update RFC 4346bis, in order to apply to TLS 1.2, if you
follow the IETF update/obsolete-versioning semantics.

I think Mark has a point here.  IETF-versioning doesn't handle
version-independent feature, unless such behaviour is explicitly
documented (which it isn't, as far as I can tell, in this case).

However, I think the solution here is to (once RFC 4346bis is published)
revise RFC 4680 to update RFC 4346bis, if there is a need from the
community to use RFC 4680 with TLS 1.2, rather than changing the TLS 1.2
specification.

/Simon

<Pasi.Eronen at nokia.com> writes:

> The text you're quoting is unchanged from TLS 1.1, and RFC 4680 is
> clearly a version-independent feature. So yes, you can use it with TLS
> 1.2 as well.
>
> (The text about ordering handshake messages in TLS 1.0/1.1/1.2 is
> intended to apply only to handshake messages defined in those
> documents; the intent is not to prevent other documents from defining
> new handshake messages that get added somewhere in the middle.)
>
> Best regards,
> Pasi 
>
>> -----Original Message-----
>> From: ext Mark Brown [mailto:mark at redphonesecurity.com] 
>> Sent: 29 February, 2008 18:38
>> To: Eronen Pasi (Nokia-NRC/Helsinki); tls at ietf.org
>> Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The 
>> TransportLayer Security (TLS) Protocol Version 1.2) to 
>> Proposed Standard
>> 
>> 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
>> 
>> > -----Original Message-----
>> > From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
>> > Sent: Friday, February 29, 2008 5:29 AM
>> > To: mark at redphonesecurity.com; tls at ietf.org
>> > Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
>> > TransportLayer Security (TLS) Protocol Version 1.2) to 
>> Proposed Standard
>> > 
>> > 
>> > 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: tls at ietf.org
>> > > Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
>> > > TransportLayer Security (TLS) Protocol Version 1.2) to
>> > > Proposed Standard
>> > >
>> > > 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
>> > > TLS at ietf.org
>> > > https://www.ietf.org/mailman/listinfo/tls
>> > >
>> 
>> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls