Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Okay, just wanted to check!

> Am 13.03.2018 um 09:30 schrieb Martin Thomson :
> 
> On Tue, Mar 13, 2018 at 8:06 AM, Mirja Kuehlewind (IETF)
>  wrote:
>> Just to double-check, there is also no requirement or maybe recommend to not 
>> send cleartext and 0-RTT data in the same packet?
> 
> You mean in the same TCP segment?  We do nothing to prevent that, and
> nor should we.  It would mess with intended uses of TCP fast open.  In
> DTLS, that extends to having a ClientHello and 0-RTT in the same UDP
> datagram, which is permitted and similarly beneficial.
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Martin Thomson]

On Tue, Mar 13, 2018 at 8:06 AM, Mirja Kuehlewind (IETF)
 wrote:
> Just to double-check, there is also no requirement or maybe recommend to not 
> send cleartext and 0-RTT data in the same packet?

You mean in the same TCP segment?  We do nothing to prevent that, and
nor should we.  It would mess with intended uses of TCP fast open.  In
DTLS, that extends to having a ClientHello and 0-RTT in the same UDP
datagram, which is permitted and similarly beneficial.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Kathleen Moriarty]

Mirja,

On Wed, Mar 7, 2018 at 2:03 PM, Eric Rescorla  wrote:
>
>
> On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF)
>  wrote:
>>
>> > > Still, I find it
>> > > especially confusing that also two TLS1.2 extensions are deprecated
>> > > which are not needed with TLS1.3 anymore but still probably valid to
>> > > be used with TLS1.2, right?
>> >
>> > Which extensions are you referring to.
>>
>> RFC5077 and RFC6961 (maybe extension is not the wrong term for the first
>> one)
>
>
> OK. I'm not really sure of a better way to handle this.
>
>
>>
>> > > I would recommend for this version to at
>> > > least already note in the abstract or very early in the intro that it
>> > > changes the versioning mechanism itself, and thereby basically
>> > > declares the TLS handshake as an invariant for all future versions and
>> > > extensibility is only provided using extensions anymore.
>> >
>> > It's true that we are deprecating the version mechanism, but that
>> > does not mean that it is the only extension mechanism.
>>
>> Which others do you have?
>
>
> Once you have negotiated a new version you can change the messages in any
> way you please, just as you always could have.
>
>
>
>> > > 2) Can you provide further explanation (potentially in the draft) why
>> > > the Pre-Shared Key Exchange Modes are provided in an extra/separate
>> > > extension?
>> >
>> > I'm sorry, I'm not following this. As opposed to what?
>>
>> You could implicitly make assumptions depending on which extension are
>> present or you can add one field to the pre_shared_key extension to indicate
>> the mode. I’m always careful is something says „if this think is present,
>> that must also be present“ as it can be an source of error that could have
>> been avoided.
>
>
> Yes, we considered this design, and rejected it because we wanted a way to
> indicate which kinds of PSKs the client would be willing to accept.
>
>
>>
>> > > 3) I know previous versions of TLS didn't say that much either, but I
>> > > find it a bit wired that there are NO requirements for the underlaying
>> > > transport in this document. Previous version this at least said in the
>> > > intro that a reliable transport (like TCP) is assumed, but even this
>> > > minimal information seems to have gotten lost in this
>> > > document. However, I would usually also expect to seen some minimal
>> > > text about connection handling, e.g. is it okay to transparently try
>> > > to reestablish the connection by the underlying transport protocol if
>> > > it broke for some reason? Or it is okay to use the same TCP connection
>> > > to first send other data and then start the TLS handshake?
>> >
>> > This is pretty explicitly outside the scope of TLS. It's just the job
>> > of the underlying transport to simulate a reliable stream. I can add
>> > some text that that's expected.
>>
>> If that is the only requirement, it would still be good to spell that out.
>>
>
> Sure, I can add something.
>
>>
>> >
>> > > 4) Regarding the registration policies: I assume the intend of
>> > > changing them is to make it easier to specify and use new
>> > > extensions/mechanism. However, I am wondering why the policies have
>> > > been changed to "Specification Required" and not "IETF consensus" or
>> > > RFC Required"?
>> >
>> > The changes aren't in this document, but the WG feeling was that
>> > both of those were creating bad incentives for people to publish
>> > RFCs just to get a code point. The "Recommended" flag was intended
>> > to address that need instead.
>>
>> Hm, I think I would actually prefer to see things documented in RFCs
>> instead of just having some spec somewhere. Not sure if an RFC on the ISE
>> stream is that much more effort than writing a spec somewhere else but then
>> at least the IESG would get to see it for a conflict review..
>
>
> Well, I can see how you would feel that way, but it was the consensus of the
> WG that that was not the right approach.

I agree with Eric and poked at this in my AD review of the recent
policy changes.  There is strong WG consensus to allow for informal
documentation such as an unpublished draft.  As such, I support that
consensus as sponsoring AD since our procedures allow for this
flexibility and it makes sense.

Thanks for your review and comments, it's helpful.
Kathleen

>
>
>
>> > > 5) I find it a bit strange that basically the whole working group is
>> > > listed as contributors. My understanding was that Contributors are
>> > > people that have contributed a "significant" amount of text, while
>> > > everybody else who e.g. brought ideas in during mailing list
>> > > discussion would be acknowledged only.
>> >
>> > I don't think we have any IETF-wide standard here, but traditionally
>> > we have adopted a pretty generous attitude towards acknowledgements
>> > of this type. Given that electrons are basically free, I don't see a
>> > real
>> > problem here.
>>
>> I just would have expected to see all 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Eric Rescorla]

On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:

> > > Still, I find it
> > > especially confusing that also two TLS1.2 extensions are deprecated
> > > which are not needed with TLS1.3 anymore but still probably valid to
> > > be used with TLS1.2, right?
> >
> > Which extensions are you referring to.
>
> RFC5077 and RFC6961 (maybe extension is not the wrong term for the first
> one)
>

OK. I'm not really sure of a better way to handle this.



> > > I would recommend for this version to at
> > > least already note in the abstract or very early in the intro that it
> > > changes the versioning mechanism itself, and thereby basically
> > > declares the TLS handshake as an invariant for all future versions and
> > > extensibility is only provided using extensions anymore.
> >
> > It's true that we are deprecating the version mechanism, but that
> > does not mean that it is the only extension mechanism.
>
> Which others do you have?
>

Once you have negotiated a new version you can change the messages in any
way you please, just as you always could have.



> > 2) Can you provide further explanation (potentially in the draft) why
> > > the Pre-Shared Key Exchange Modes are provided in an extra/separate
> > > extension?
> >
> > I'm sorry, I'm not following this. As opposed to what?
>
> You could implicitly make assumptions depending on which extension are
> present or you can add one field to the pre_shared_key extension to
> indicate the mode. I’m always careful is something says „if this think is
> present, that must also be present“ as it can be an source of error that
> could have been avoided.


Yes, we considered this design, and rejected it because we wanted a way to
indicate which kinds of PSKs the client would be willing to accept.



> > > 3) I know previous versions of TLS didn't say that much either, but I
> > > find it a bit wired that there are NO requirements for the underlaying
> > > transport in this document. Previous version this at least said in the
> > > intro that a reliable transport (like TCP) is assumed, but even this
> > > minimal information seems to have gotten lost in this
> > > document. However, I would usually also expect to seen some minimal
> > > text about connection handling, e.g. is it okay to transparently try
> > > to reestablish the connection by the underlying transport protocol if
> > > it broke for some reason? Or it is okay to use the same TCP connection
> > > to first send other data and then start the TLS handshake?
> >
> > This is pretty explicitly outside the scope of TLS. It's just the job
> > of the underlying transport to simulate a reliable stream. I can add
> > some text that that's expected.
>
> If that is the only requirement, it would still be good to spell that out.
>
>
Sure, I can add something.


> >
> > > 4) Regarding the registration policies: I assume the intend of
> > > changing them is to make it easier to specify and use new
> > > extensions/mechanism. However, I am wondering why the policies have
> > > been changed to "Specification Required" and not "IETF consensus" or
> > > RFC Required"?
> >
> > The changes aren't in this document, but the WG feeling was that
> > both of those were creating bad incentives for people to publish
> > RFCs just to get a code point. The "Recommended" flag was intended
> > to address that need instead.
>
> Hm, I think I would actually prefer to see things documented in RFCs
> instead of just having some spec somewhere. Not sure if an RFC on the ISE
> stream is that much more effort than writing a spec somewhere else but then
> at least the IESG would get to see it for a conflict review..


Well, I can see how you would feel that way, but it was the consensus of
the WG that that was not the right approach.



> > 5) I find it a bit strange that basically the whole working group is
> > > listed as contributors. My understanding was that Contributors are
> > > people that have contributed a "significant" amount of text, while
> > > everybody else who e.g. brought ideas in during mailing list
> > > discussion would be acknowledged only.
> >
> > I don't think we have any IETF-wide standard here, but traditionally
> > we have adopted a pretty generous attitude towards acknowledgements
> > of this type. Given that electrons are basically free, I don't see a real
> > problem here.
>
> I just would have expected to see all these names in an acknowledgment
> section and not in an contributor section.
>
> RFC7322 again says:
>
> "4.11.  Contributors Section
>
>
>
>This optional section acknowledges those who have made significant
>contributions to the document.“
>

I think this is within WG and Editor discretion.

-Ekr


>
> Mirja
>
>
>
> >
> > -Ekr
> >
> >
> > On Wed, Mar 7, 2018 at 8:38 AM, Mirja Kühlewind 
> wrote:
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-tls-tls13-26: No Objection
> >
> > When responding, please 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Hi,

see below

> Am 07.03.2018 um 19:05 schrieb Eric Rescorla :
> 
> > 1) I'm a bit uncertain if obsoleting is the right approach as many
> > other protocols usually do not obsolete older versions. However, I
> > understand that this has been the approach TLS has previously taken
> > and is supported by the way the document is written.
> 
> Well:
> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
> says:
> A document is obsolete when there is a newer version that replaces it.
> 
> I believe that that's the relationship between TLS 1.3 and TLS 1.2.

I looked at this and was wondering if this is meant to rather mean newer 
version of the same document than actual protocol version.

I found this in RFC2223 (which is obsoleted by 7322 which however doesn’t give 
a definition):

"Obsoletes

  To be used to refer to an earlier document that is replaced by
  this document.  This document contains either revised information,
  or else all of the same information plus some new information,
  however extensive or brief that new information is; i.e., this
  document can be used alone, without reference to the older
  document.“

Anyway, as I said I know why you did this; it still seem wired to me.

> 
> 
> > Still, I find it
> > especially confusing that also two TLS1.2 extensions are deprecated
> > which are not needed with TLS1.3 anymore but still probably valid to
> > be used with TLS1.2, right?
> 
> Which extensions are you referring to.

RFC5077 and RFC6961 (maybe extension is not the wrong term for the first one)
> 
> 
> > I would recommend for this version to at
> > least already note in the abstract or very early in the intro that it
> > changes the versioning mechanism itself, and thereby basically
> > declares the TLS handshake as an invariant for all future versions and
> > extensibility is only provided using extensions anymore.
> 
> It's true that we are deprecating the version mechanism, but that
> does not mean that it is the only extension mechanism.

Which others do you have?

> 
> 
> 
> > 2) Can you provide further explanation (potentially in the draft) why
> > the Pre-Shared Key Exchange Modes are provided in an extra/separate
> > extension?
> 
> I'm sorry, I'm not following this. As opposed to what?

You could implicitly make assumptions depending on which extension are present 
or you can add one field to the pre_shared_key extension to indicate the mode. 
I’m always careful is something says „if this think is present, that must also 
be present“ as it can be an source of error that could have been avoided.

> 
> 
> > 3) I know previous versions of TLS didn't say that much either, but I
> > find it a bit wired that there are NO requirements for the underlaying
> > transport in this document. Previous version this at least said in the
> > intro that a reliable transport (like TCP) is assumed, but even this
> > minimal information seems to have gotten lost in this
> > document. However, I would usually also expect to seen some minimal
> > text about connection handling, e.g. is it okay to transparently try
> > to reestablish the connection by the underlying transport protocol if
> > it broke for some reason? Or it is okay to use the same TCP connection
> > to first send other data and then start the TLS handshake?
> 
> This is pretty explicitly outside the scope of TLS. It's just the job
> of the underlying transport to simulate a reliable stream. I can add
> some text that that's expected.

If that is the only requirement, it would still be good to spell that out.
> 
> 
> > 4) Regarding the registration policies: I assume the intend of
> > changing them is to make it easier to specify and use new
> > extensions/mechanism. However, I am wondering why the policies have
> > been changed to "Specification Required" and not "IETF consensus" or
> > RFC Required"?
> 
> The changes aren't in this document, but the WG feeling was that
> both of those were creating bad incentives for people to publish
> RFCs just to get a code point. The "Recommended" flag was intended
> to address that need instead.

Hm, I think I would actually prefer to see things documented in RFCs instead of 
just having some spec somewhere. Not sure if an RFC on the ISE stream is that 
much more effort than writing a spec somewhere else but then at least the IESG 
would get to see it for a conflict review...

> 
> 
> > 5) I find it a bit strange that basically the whole working group is
> > listed as contributors. My understanding was that Contributors are
> > people that have contributed a "significant" amount of text, while
> > everybody else who e.g. brought ideas in during mailing list
> > discussion would be acknowledged only.
> 
> I don't think we have any IETF-wide standard here, but traditionally
> we have adopted a pretty generous attitude towards acknowledgements
> of this type. Given that electrons are basically free, I don't see a real
> problem here.

I just 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Kathleen Moriarty]

Thanks for your review, Mirja.  I will just add one comment inline
from WG discussion and consensus.

On Wed, Mar 7, 2018 at 1:05 PM, Eric Rescorla  wrote:
>> 1) I'm a bit uncertain if obsoleting is the right approach as many
>> other protocols usually do not obsolete older versions. However, I
>> understand that this has been the approach TLS has previously taken
>> and is supported by the way the document is written.
>
> Well:
> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
> says:
> A document is obsolete when there is a newer version that replaces it.
>
> I believe that that's the relationship between TLS 1.3 and TLS 1.2.
>
>
>> Still, I find it
>> especially confusing that also two TLS1.2 extensions are deprecated
>> which are not needed with TLS1.3 anymore but still probably valid to
>> be used with TLS1.2, right?
>
> Which extensions are you referring to.
>
>
>> I would recommend for this version to at
>> least already note in the abstract or very early in the intro that it
>> changes the versioning mechanism itself, and thereby basically
>> declares the TLS handshake as an invariant for all future versions and
>> extensibility is only provided using extensions anymore.
>
> It's true that we are deprecating the version mechanism, but that
> does not mean that it is the only extension mechanism.
>
>
>
>> 2) Can you provide further explanation (potentially in the draft) why
>> the Pre-Shared Key Exchange Modes are provided in an extra/separate
>> extension?
>
> I'm sorry, I'm not following this. As opposed to what?
>
>
>> 3) I know previous versions of TLS didn't say that much either, but I
>> find it a bit wired that there are NO requirements for the underlaying
>> transport in this document. Previous version this at least said in the
>> intro that a reliable transport (like TCP) is assumed, but even this
>> minimal information seems to have gotten lost in this
>> document. However, I would usually also expect to seen some minimal
>> text about connection handling, e.g. is it okay to transparently try
>> to reestablish the connection by the underlying transport protocol if
>> it broke for some reason? Or it is okay to use the same TCP connection
>> to first send other data and then start the TLS handshake?
>
> This is pretty explicitly outside the scope of TLS. It's just the job
> of the underlying transport to simulate a reliable stream. I can add
> some text that that's expected.
>
>
>> 4) Regarding the registration policies: I assume the intend of
>> changing them is to make it easier to specify and use new
>> extensions/mechanism. However, I am wondering why the policies have
>> been changed to "Specification Required" and not "IETF consensus" or
>> RFC Required"?
>
> The changes aren't in this document, but the WG feeling was that
> both of those were creating bad incentives for people to publish
> RFCs just to get a code point. The "Recommended" flag was intended
> to address that need instead.

The working group explicitly feels that a draft that is not published
is adequate, falling into the specification required category where
informal documentation is acceptable.


Thanks,
Kathleen

>
>
>> 5) I find it a bit strange that basically the whole working group is
>> listed as contributors. My understanding was that Contributors are
>> people that have contributed a "significant" amount of text, while
>> everybody else who e.g. brought ideas in during mailing list
>> discussion would be acknowledged only.
>
> I don't think we have any IETF-wide standard here, but traditionally
> we have adopted a pretty generous attitude towards acknowledgements
> of this type. Given that electrons are basically free, I don't see a real
> problem here.
>
> -Ekr
>
>
> On Wed, Mar 7, 2018 at 8:38 AM, Mirja Kühlewind  wrote:
>>
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-tls-tls13-26: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> 1) I'm a bit uncertain if obsoleting is the right approach as many other
>> protocols usually do not obsolete older versions. However, I understand
>> that
>> this has been the approach TLS has previously taken and is supported by
>> the way
>> the document is written. Still, I find it especially confusing that also
>> two
>> TLS1.2 extensions are deprecated which are not needed with TLS1.3 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Eric Rescorla]

> 1) I'm a bit uncertain if obsoleting is the right approach as many
> other protocols usually do not obsolete older versions. However, I
> understand that this has been the approach TLS has previously taken
> and is supported by the way the document is written.

Well:
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
says:
A document is obsolete when there is a newer version that replaces it.

I believe that that's the relationship between TLS 1.3 and TLS 1.2.


> Still, I find it
> especially confusing that also two TLS1.2 extensions are deprecated
> which are not needed with TLS1.3 anymore but still probably valid to
> be used with TLS1.2, right?

Which extensions are you referring to.


> I would recommend for this version to at
> least already note in the abstract or very early in the intro that it
> changes the versioning mechanism itself, and thereby basically
> declares the TLS handshake as an invariant for all future versions and
> extensibility is only provided using extensions anymore.

It's true that we are deprecating the version mechanism, but that
does not mean that it is the only extension mechanism.



> 2) Can you provide further explanation (potentially in the draft) why
> the Pre-Shared Key Exchange Modes are provided in an extra/separate
> extension?

I'm sorry, I'm not following this. As opposed to what?


> 3) I know previous versions of TLS didn't say that much either, but I
> find it a bit wired that there are NO requirements for the underlaying
> transport in this document. Previous version this at least said in the
> intro that a reliable transport (like TCP) is assumed, but even this
> minimal information seems to have gotten lost in this
> document. However, I would usually also expect to seen some minimal
> text about connection handling, e.g. is it okay to transparently try
> to reestablish the connection by the underlying transport protocol if
> it broke for some reason? Or it is okay to use the same TCP connection
> to first send other data and then start the TLS handshake?

This is pretty explicitly outside the scope of TLS. It's just the job
of the underlying transport to simulate a reliable stream. I can add
some text that that's expected.


> 4) Regarding the registration policies: I assume the intend of
> changing them is to make it easier to specify and use new
> extensions/mechanism. However, I am wondering why the policies have
> been changed to "Specification Required" and not "IETF consensus" or
> RFC Required"?

The changes aren't in this document, but the WG feeling was that
both of those were creating bad incentives for people to publish
RFCs just to get a code point. The "Recommended" flag was intended
to address that need instead.


> 5) I find it a bit strange that basically the whole working group is
> listed as contributors. My understanding was that Contributors are
> people that have contributed a "significant" amount of text, while
> everybody else who e.g. brought ideas in during mailing list
> discussion would be acknowledged only.

I don't think we have any IETF-wide standard here, but traditionally
we have adopted a pretty generous attitude towards acknowledgements
of this type. Given that electrons are basically free, I don't see a real
problem here.

-Ekr


On Wed, Mar 7, 2018 at 8:38 AM, Mirja Kühlewind  wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-tls13-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
>
>
> --
> COMMENT:
> --
>
> 1) I'm a bit uncertain if obsoleting is the right approach as many other
> protocols usually do not obsolete older versions. However, I understand
> that
> this has been the approach TLS has previously taken and is supported by
> the way
> the document is written. Still, I find it especially confusing that also
> two
> TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore
> but
> still probably valid to be used with TLS1.2, right? I would recommend for
> this
> version to at least already note in the abstract or very early in the intro
> that it changes the versioning mechanism itself, and thereby basically
> declares
> the TLS handshake as an invariant for all future versions and
> extensibility is
> only provided using extensions anymore.
>
> 2) Can you provide further explanation (potentially in the draft) why the
> Pre-Shared Key Exchange Modes are provided 

[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Mirja Kühlewind]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tls-tls13-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/



--
COMMENT:
--

1) I'm a bit uncertain if obsoleting is the right approach as many other
protocols usually do not obsolete older versions. However, I understand that
this has been the approach TLS has previously taken and is supported by the way
the document is written. Still, I find it especially confusing that also two
TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore but
still probably valid to be used with TLS1.2, right? I would recommend for this
version to at least already note in the abstract or very early in the intro
that it changes the versioning mechanism itself, and thereby basically declares
the TLS handshake as an invariant for all future versions and extensibility is
only provided using extensions anymore.

2) Can you provide further explanation (potentially in the draft) why the
Pre-Shared Key Exchange Modes are provided in an extra/separate extension?

3) I know previous versions of TLS didn't say that much either, but I find it a
bit wired that there are NO requirements for the underlaying transport in this
document. Previous version this at least said in the intro that a reliable
transport (like TCP) is assumed, but even this minimal information seems to
have gotten lost in this document. However, I would usually also expect to seen
some minimal text about connection handling, e.g. is it okay to transparently
try to reestablish the connection by the underlying transport protocol if it
broke for some reason? Or it is okay to use the same TCP connection to first
send other data and then start the TLS handshake?

4) Regarding the registration policies: I assume the intend of changing them is
to make it easier to specify and use new extensions/mechanism. However, I am
wondering why the policies have been changed to "Specification Required" and
not "IETF consensus" or RFC Required"?

5) I find it a bit strange that basically the whole working group is listed as
contributors. My understanding was that Contributors are people that have
contributed a "significant" amount of text, while everybody else who e.g.
brought ideas in during mailing list discussion would be acknowledged only.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls