Subject: [TLS] Mentioning DTLS

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Mar 2014 10:27:47 -0700

It's a minor point, but ALPN only mentions UDP once (in the abstract)
and DTLS not at all.

I have to assume that DTLS is an intended part of this, but others
have been confused by the lack of mention.

Could this be corrected?  A mention of DTLS in the first line of the
introduction should suffice.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 13 Mar 2014 19:51:38 +0000

Mentioning DTLS makes sense; I have no objection to making this change in the next revision.

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Thursday, March 13, 2014 10:28 AM
To: [email-masked]; [email-masked]
Subject: [TLS] Mentioning DTLS

It's a minor point, but ALPN only mentions UDP once (in the abstract) and DTLS not at all.

I have to assume that DTLS is an intended part of this, but others have been confused by the lack of mention.

Could this be corrected?  A mention of DTLS in the first line of the introduction should suffice.

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

---

From: [email-masked] (Martin Rex)
Date: Fri, 14 Mar 2014 22:04:18 +0100 (CET)

> change in the next revision.

Speaking of DTLS.

NEITHER of the two official DTLS specifications of the IETF does support
TLS extensions.  There exists no definition of a TLS ClientHello PDU
that provides room for (D)TLS extensions, and there is no forward
extensibility notice for the DTLS ClientHello PDU in the fashion
that was retrofitted into the SSLv3 specification.

If DTLS was supposed to allow TLS extensions in the DTLS ClientHello PDU,
then someone (preferably a DTLS implementor or one of the document
authors) really should file erratas with a description of the
DTLS ExtendendedClientHello and DTLS ExtendedServerHello PDUs for
both DTLS specifications (rfc4347 and rfc6347).

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Mar 2014 14:10:01 -0700

On 14 March 2014 14:04, Martin Rex <[email-masked]> wrote:
> TLS extensions.

I don't know how you came to that conclusion.  The definition of
ClientHello is inherited from the corresponding TLS specification,
isn't it?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Mar 2014 15:11:33 -0700

> ClientHello is inherited from the corresponding TLS specification,

I see what the problem is now.  It looks like 6347 and co have opted
to omit the extensions.  Most implementations I know of support
extension, even though this was omitted.  Erratum on 6347 filed (4347
is obsolete, so I'm not going to bother with it).

http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Mar 2014 15:25:01 -0700

Martin R, thanks for pointing this out. Good catch.

Martin T, thanks for the errata!

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Mar 2014 00:47:31 +0000

So assuming nobody finds a problem with the erratum
(and I remember;-) I'll mark it approved in a day or
so.

S

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Mar 2014 13:44:07 -0400

> (and I remember;-) I'll mark it approved in a day or

While this is a valid errata submission, reading 
https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 
suggests
that since this was present all the way back in 2006 and not fixed in 
this version, what the IESG is going to do is mark it as Hold for 
Document Update.   And we really should be implementing what's been 
written down, rather than writing down what's been implemented - at 
least for RFCs!

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Mar 2014 18:21:33 +0000

> written down, rather than writing down what's been implemented - at

I'll take that as someone claiming there's a problem then
and wait on the chairs to tell me what they figure the WG
consensus is on processing this.

S.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 16 Mar 2014 21:08:35 +0100

On 16 Mar 2014, at 18:44, Michael StJohns <[email-masked]> wrote:

> While this is a valid errata submission, reading https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 suggests
> that since this was present all the way back in 2006 and not fixed in this version, what the IESG is going to do is mark it as Hold for Document Update.   And we really should be implementing what's been written down, rather than writing down what's been implemented - at least for RFCs!
Hi Mike,

please note that there are also RFCs specifying DTLS extensions. See
http://tools.ietf.org/html/rfc6520
So I think this is really an errata, as Martin Thomson pointed out.

Best regards
Michael

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Mar 2014 16:28:06 -0400

> consensus is on processing this.

Hi Stephen -

Wasn't objecting, just pointing out that the IESG may end up requiring 
an RFC to fix this and that we should be prepared for that.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Mar 2014 16:29:24 -0400

> So I think this is really an errata, as Martin Thomson pointed out.

It is an errata - but the handling of errata has three outputs, only one 
of which is "We heard it, you're good to go"  :-)

But your point is taken, and that fact should be included in the errata 
justification.