Subject: [TLS] DTLS lacking TLS extensions ?

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 02:30:06 +0100 (MET)

I'm somewhat confused about whether TLS extensions apply to DTLS.

DTLS 1.0 and 1.2 redefine the ClientHello PDU:
  http://tools.ietf.org/html/rfc4347#page-12
  http://tools.ietf.org/html/rfc6347#page-16

but I did not see the Forward Compatibility Notice from rfc2246

  http://tools.ietf.org/html/rfc2246#page-36
  
for data trailing the Compression Methods in that new DtlsClientHello PDU
in rfc4347 and rfc6347, nor do I see a definition of an
ExtendedDtlsClientHello PDU in TLS extensions (rfc4366).

The most confusing part: You can not implement rfc5746
(TLS extension renegotiation_info) for DTLS without that.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Jan 2012 17:40:07 -0800

Good point.

DTLS is intended to support extensions--and OpenSSL, at least,
supports them in the same way as it does for TLS.

There probably should be a definition of ExtendedClientHello
in 4346 and 6347, but it's exactly the PDU you would expect.
I.e., the extensions come after the CompressionMethod.

-Ekr

On Wed, Jan 25, 2012 at 5:30 PM, Martin Rex <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 03:13:36 +0100 (MET)

> I.e., the extensions come after the CompressionMethod.

That is what I would have expected.

But I'm not a DTLS implementor, so I can not comment on implementations.

Maybe it is what everyone has been silently doing.  Trying to implement
rfc5746 in DTLS should have raised some eyebrowse if this was
"unexpected", I would assume.

suggested changes:

4347:

  add this into the DTLS ClientHello PDU definition on page-12
  as last element following CompressionMethod:

          Extension client_hello_extension_list<0..2^16-1>;

  add a normative reference to rfc4366 to section 8.1
  for a description of the new Extension element:

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

6347:

  add this into the DTLS ClientHello PDU definition on page-16
  as last element following CompressionMethod:

       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };

  re-using the existing normative reference to rfc5246

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Jan 2012 00:21:31 -0600

On 01/25/2012 08:13 PM, Martin Rex wrote:
>
> Maybe it is what everyone has been silently doing.  Trying to
> implement rfc5746 in DTLS should have raised some eyebrowse if this
> was "unexpected", I would assume.

As I recall it, there were indeed a few eyebrows raised at RFC 5746!

There was no shortage of discussion about the protocol "legality" of
sending extensions on an SSLv3 Client Hello. (Scare quotes because there
appear to have been multiple versions of the SSL 3.0 spec published on
the web at different times).

Given the reality of the huge number of SSLv3 implementations in use,
the relative rarity of DTLS and the fact that it is an actively
maintained spec, we probably didn't feel it necessary to revise more
for DTLS than what was added in 5746:

http://tools.ietf.org/html/rfc5746
> This extension also can be used with Datagram TLS (DTLS) [RFC4347].
> Although, for editorial simplicity, this document refers to TLS, all
> requirements in this document apply equally to DTLS.

- Marsh