Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Feb 2013 10:51:18 +0000

Eric Rescorla <[email-masked]> writes:

>WG members, please provide any comments on whether we should take this work
>on by February 21. Additionally, if you wish to propose an alternative, it
>would be nice if you could do so soon or at least provide an indication of
>interest.

A comment on both of these proposals, to encode their protocols they use an
ad-hoc, non-TLS-style encoding whose form is rather unclear:

  Protocols are named by IANA registered, opaque, non-empty byte strings and
  the list of protocols is serialized as a concatenation of 8-bit, length
  prefixed byte strings.

Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or
neither?  What's wrong with:

  opaque ProtocolName<1..2^16-1>;

  struct {
      ProtocolName protocol_name_list<1..2^16-1>
      } ProtocolNameList;

which fits the way everything else is done in TLS?

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Feb 2013 11:41:27 +0000

> neither?  What's wrong with:

I agree that it's not clean, but I took it to mean ...serialized as a concatenation of (((8-bit length) prefixed) byte strings)

So a byte length followed by that many bytes of string, followed by another byte length, and so on.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 8 Feb 2013 19:33:34 +0000

I agree that the current language is unclear; Peter's suggestion looks good to me.

Thanks,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Friday, February 8, 2013 2:51 AM
To: [email-masked]
Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols

Eric Rescorla <[email-masked]> writes:

>WG members, please provide any comments on whether we should take this 
>work on by February 21. Additionally, if you wish to propose an 
>alternative, it would be nice if you could do so soon or at least 
>provide an indication of interest.

A comment on both of these proposals, to encode their protocols they use an ad-hoc, non-TLS-style encoding whose form is rather unclear:

Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or neither?  What's wrong with:

  struct {

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

---

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Fri, 8 Feb 2013 21:18:23 +0000

Though I wasn't in Atlanta, taking on this work seems to make plenty of sense.

Also, agreed on using a more standard TLS encoding - that also makes plenty of sense.

Thanks!

Stephan

-----Original Message-----
From: Andrei Popov [mailto:[email-masked]] 
Sent: Friday, February 08, 2013 12:34 PM
To: Peter Gutmann; [email-masked]
Cc: Stephan Friedl (sfriedl)
Subject: RE: [TLS] Confirming Consensus: Negotiating upper layer protocols

Thanks,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Friday, February 8, 2013 2:51 AM
To: [email-masked]
Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols

  struct {

Peter.

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Feb 2013 23:33:10 +0100 (CET)

> which fits the way everything else is done in TLS?

Do we really need ProtocolNames > 255 chars?

Btw. the lower bounds of container elements are usually
set to the minimum possible length.  In your example,
the lower bounds of protocol_name_list would be 3, I believe.

How about

   opaque ProtocolName<1..2^8-1>;

   struct {
       ProtocolName protocol_name_list<2..2^16-1>
   } ProtocolNameList;

-Martin