Re: [TLS] DTLS lacking TLS extensions ?
Martin Rex <mrex@sap.com> Thu, 26 January 2012 02:13 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C5611E8096 for <tls@ietfa.amsl.com>; Wed, 25 Jan 2012 18:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.16
X-Spam-Level:
X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oQzouneWdA3 for <tls@ietfa.amsl.com>; Wed, 25 Jan 2012 18:13:39 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B1AC111E808C for <tls@ietf.org>; Wed, 25 Jan 2012 18:13:38 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0Q2Dbdv014720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 03:13:37 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201201260213.q0Q2Dadk027323@fs4113.wdf.sap.corp>
To: ekr@rtfm.com
Date: Thu, 26 Jan 2012 03:13:36 +0100
In-Reply-To: <CABcZeBP1a793wUPMNrjp9zWpVkarvaXvqzQ486rKupa+9jRR-A@mail.gmail.com> from "Eric Rescorla" at Jan 25, 12 05:40:07 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS lacking TLS extensions ?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2012 02:13:39 -0000
Eric Rescorla wrote:
>
> 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.
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
- [TLS] DTLS lacking TLS extensions ? Martin Rex
- Re: [TLS] DTLS lacking TLS extensions ? Eric Rescorla
- Re: [TLS] DTLS lacking TLS extensions ? Martin Rex
- Re: [TLS] DTLS lacking TLS extensions ? Marsh Ray