[TLS] record layer limits of TLS1.3

[Nikos Mavrogiannopoulos]

Hi,
 Up to the current draft of TLS1.3 the record layer is restricted to
sending 2^14 or less. Is the 2^14 number something we want to preserve?
16kb used to be a lot, but today if one wants to do fast data transfers
most likely he would prefer to use larger blocks. Given that the length
field allows for sizes up to 2^16, shouldn't the draft allow for 2^16-
1024 as maximum?

regards,
Nikos

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

Re: [TLS] Labels in HKDF-Expand-Label

[Eric Rescorla]

Actually all future EXPORTERs need to start with EXPORTER-. But this does
seem like a reasonable change so I have merged it

-Ekr


On Tue, Nov 22, 2016 at 9:25 PM, Martin Thomson 
wrote:

> The grammar for the label permits the label to be 9 octets long.
> That's the exact length of the prefix.
>
> That means that it is valid to use an exporter with an empty label
> string.  That seems dangerous.  I propose that we require at least one
> octet:
>
> https://github.com/tlswg/tls13-spec/pull/774
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Labels in HKDF-Expand-Label

[Martin Thomson]

The grammar for the label permits the label to be 9 octets long.
That's the exact length of the prefix.

That means that it is valid to use an exporter with an empty label
string.  That seems dangerous.  I propose that we require at least one
octet:

https://github.com/tlswg/tls13-spec/pull/774

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Anders Rundgren]

Using the YEAR as Version was created to make sure that users having old 
versions
of products that are constantly upgraded would feel the pressure to upgrade.

This idea doesn't seem equally suitable for security protocols.

TLS 4 would IMO be a logical choice since it is numerically higher than all its 
predecessors.

Anders

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

Re: [TLS] Draft 18 review : Message splitting and interleaving

[Eric Rescorla]

On Tue, Nov 22, 2016 at 4:36 PM, Martin Thomson 
wrote:

> On 23 November 2016 at 10:24, Eric Rescorla  wrote:
> >>   [EncryptedExtensions Certifi]
> >>   [cateRequest Certificate Cer]
> >>   [tificateVerify Finished]
> >
> >
> > Yeah, that's how this works in NSS.
>
> To be clear, NSS buffers an entire flight of messages and then sends
> them.  It might fragment things between TCP segments as a result, but
> usually fits everything in a single record (with some exceptions,
> thanks to CertificateRequest being bloated, foor example).  (In DTLS,
> it's more complicated because we have MTU detection, but the same
> basic principle applies.)
>

Yes, this is what I meant to say. Basically, it tries to cram as much as it
can into
one record and the answer to "as much as it can" is "it depends"

-Ekr


Like others, I would find stricter rules around record splits very
> hard to enforce, and for not much gain.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 review : Message splitting and interleaving

[Martin Thomson]

On 23 November 2016 at 10:24, Eric Rescorla  wrote:
>>   [EncryptedExtensions Certifi]
>>   [cateRequest Certificate Cer]
>>   [tificateVerify Finished]
>
>
> Yeah, that's how this works in NSS.

To be clear, NSS buffers an entire flight of messages and then sends
them.  It might fragment things between TCP segments as a result, but
usually fits everything in a single record (with some exceptions,
thanks to CertificateRequest being bloated, foor example).  (In DTLS,
it's more complicated because we have MTU detection, but the same
basic principle applies.)

Like others, I would find stricter rules around record splits very
hard to enforce, and for not much gain.

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

Re: [TLS] Draft 18 review : Message splitting and interleaving

[Eric Rescorla]

On Tue, Nov 22, 2016 at 2:18 PM, David Benjamin 
wrote:

> On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain <
> olivier.levill...@ssi.gouv.fr> wrote:
>
>> Hi list,
>>
>> I am sorry for the very late answer concerning draft 18, but we
>> (ANSSI) have several remarks after proof-reading the current
>> specification.
>>
>> We are sorry for the multiple long messages.
>>
>> If the WG is interested by some of our concerns/proposals, we would be
>> glad to propose some PRs.
>>
>>
>> = Message splitting and interleaving =
>>
>> How to split and interleave subprotocols in TLS has not been clearly
>> specified in the past, and it would be useful to be crystal clear on
>> this point.
>>
>> In the specification, the subject is first presented in 4.5 (P.61):
>>Handshake messages sent after the handshake MUST NOT be interleaved
>>with other record types.  That is, if a message is split over two or
>>more handshake records, there MUST NOT be any other records between
>>them.
>> But I am wondering why this text only concern "messages after the
>> handshake".  It should always be the case!
>>
>> It is next present in section 4.5.3 (P.64):
>>Handshake messages MUST NOT span key changes.  Because the
>>ServerHello, Finished, and KeyUpdate messages signal a key change,
>>upon receiving these messages a receiver MUST verify that the end of
>>these messages aligns with a record boundary; if not, then it MUST
>>terminate the connection with an "unexpected_message" alert.
>>
>> And then in section 5 (mostly P.64 and P.65) plus a repetition P.69.
>>
>>
>> It is worth noting that this specific point was (at least partially)
>> the origin of several security issues:
>>  - the alert attack (https://www.mitls.org/pages/attacks/Alert);
>>  - Heartbleed (where OpenSSL answered with a fragmented record whereas
>>it was not the spirit of the spec);
>>  - the OpenSSL Downgrade attack in 2014.
>>
>> Some of this is covered in the current specification, but it might be
>> worth being even stricter:
>>  - regarding splitting/merging, they should be forbidden by default;
>>  - the default would apply to alerts (currently, the spec states that
>>alerts MUST not be split, but they should not be merged either
>>for simplicity's sake and since it is useless);
>>
>
> +1. We (BoringSSL) and I believe NSS already forbid this for alerts at all
> versions.
>
> This rule is actually implied by TLS 1.3 already, because we've gotten rid
> of warning alerts. All alerts terminate the connection, except for
> end_of_early_data, and end_of_early_data immediately signals a key change.
> So it is not legal to send two alerts in the same epoch, much less in the
> same record. (Being explicit about this is good, of course.)
>

This seems fine. I would take a PR for this.


 - incidentally, the default behaviour would apply to Heartbeat, as
>>was the intent of the specification;
>>  - ApplicationData should be considered as a stream with possibly
>>0-length records
>>  - Handshake messages should either come as a sequence of multiple
>>*entire* messages, or as a fraction of *one* message.  That is,
>>the number of HS messages inside one record should either be a
>>round number or strictly less than 1.
>>
>
> What simplifications were you expecting out of this? It seems to me this
> would be a nuisance to both enforce as a receiver and honor as a sender.
>
> Our implementation doesn't try to pack handshake messages into records,
> but I believe NSS does. NSS folks should confirm, but I expect such
> implementations just buffer the messages up and flush when the buffer
> exceeds the records size. That means all kinds of splits are plausible:
>
>   [EncryptedExtensions Certifi]
>   [cateRequest Certificate Cer]
>   [tificateVerify Finished]
>

Yeah, that's how this works in NSS.

I'm not seeing a real benefit in prohibiting this behavior.

-Ekr

I share your dislike of the way handshake messages and record boundaries
> interact (or, rather, don't), but I'm not sure how this rule helps.
>
>
>> These constraints can be expressed in 5.1 and cover most of the
>> problematic cases.  They are easy to check and to enforce.
>>
>>
>> However, the problem of the OpenSSL Downgrade flaw (where the first
>> record containing the beginning of the ClientHello was cut before the
>> ClientHello.version field) will still stand, but there is no simple
>> way to fix this, since version negotiation can now happen anywhere in
>> the ClientHello extensions, so it might be impossible to enforce that
>> the client versions are sent in the first record.
>>
>> I might volunteer some text if there is an interest of the WG.
>>
>>
>> Olivier Levillain
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> ___
> TLS mailing list
> TLS@ietf.org
> 

Re: [TLS] Draft 18 review : Message splitting and interleaving

[David Benjamin]

On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = Message splitting and interleaving =
>
> How to split and interleave subprotocols in TLS has not been clearly
> specified in the past, and it would be useful to be crystal clear on
> this point.
>
> In the specification, the subject is first presented in 4.5 (P.61):
>Handshake messages sent after the handshake MUST NOT be interleaved
>with other record types.  That is, if a message is split over two or
>more handshake records, there MUST NOT be any other records between
>them.
> But I am wondering why this text only concern "messages after the
> handshake".  It should always be the case!
>
> It is next present in section 4.5.3 (P.64):
>Handshake messages MUST NOT span key changes.  Because the
>ServerHello, Finished, and KeyUpdate messages signal a key change,
>upon receiving these messages a receiver MUST verify that the end of
>these messages aligns with a record boundary; if not, then it MUST
>terminate the connection with an "unexpected_message" alert.
>
> And then in section 5 (mostly P.64 and P.65) plus a repetition P.69.
>
>
> It is worth noting that this specific point was (at least partially)
> the origin of several security issues:
>  - the alert attack (https://www.mitls.org/pages/attacks/Alert);
>  - Heartbleed (where OpenSSL answered with a fragmented record whereas
>it was not the spirit of the spec);
>  - the OpenSSL Downgrade attack in 2014.
>
> Some of this is covered in the current specification, but it might be
> worth being even stricter:
>  - regarding splitting/merging, they should be forbidden by default;
>  - the default would apply to alerts (currently, the spec states that
>alerts MUST not be split, but they should not be merged either
>for simplicity's sake and since it is useless);
>

+1. We (BoringSSL) and I believe NSS already forbid this for alerts at all
versions.

This rule is actually implied by TLS 1.3 already, because we've gotten rid
of warning alerts. All alerts terminate the connection, except for
end_of_early_data, and end_of_early_data immediately signals a key change.
So it is not legal to send two alerts in the same epoch, much less in the
same record. (Being explicit about this is good, of course.)


>  - incidentally, the default behaviour would apply to Heartbeat, as
>was the intent of the specification;
>  - ApplicationData should be considered as a stream with possibly
>0-length records
>  - Handshake messages should either come as a sequence of multiple
>*entire* messages, or as a fraction of *one* message.  That is,
>the number of HS messages inside one record should either be a
>round number or strictly less than 1.
>

What simplifications were you expecting out of this? It seems to me this
would be a nuisance to both enforce as a receiver and honor as a sender.

Our implementation doesn't try to pack handshake messages into records, but
I believe NSS does. NSS folks should confirm, but I expect such
implementations just buffer the messages up and flush when the buffer
exceeds the records size. That means all kinds of splits are plausible:

  [EncryptedExtensions Certifi]
  [cateRequest Certificate Cer]
  [tificateVerify Finished]

I share your dislike of the way handshake messages and record boundaries
interact (or, rather, don't), but I'm not sure how this rule helps.


> These constraints can be expressed in 5.1 and cover most of the
> problematic cases.  They are easy to check and to enforce.
>
>
> However, the problem of the OpenSSL Downgrade flaw (where the first
> record containing the beginning of the ClientHello was cut before the
> ClientHello.version field) will still stand, but there is no simple
> way to fix this, since version negotiation can now happen anywhere in
> the ClientHello extensions, so it might be impossible to enforce that
> the client versions are sent in the first record.
>
> I might volunteer some text if there is an interest of the WG.
>
>
> Olivier Levillain
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Dave Garrett]

(replies to a bunch of ideas in this thread)

As the person who lit the match under this latest bikeshed debate, personally, 
I don't see a strong consensus building here. Leaving the bikeshed unpainted 
seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if 
that's the result here.

That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth 
version of TLS" message. It makes a kind of messy sense that's kind of fitting 
for TLS. I'm no longer against it.

I've also suggested highlighting the year in the past, but only in the context 
of the title and messaging, not actually replacing the version number itself. 
I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and 
changing it to 2017, wholesale. That just feels even more confusing.

Lastly, I am vehemently against the suggestion of ditching the TLS name in 
favor of SSL again, as was also brought up in this thread. SSL is dead and 
insecure, and that message needs to stay. We need to get people to stop 
conflating the two and making this worse, not accepting it.


Dave


On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote:
> I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the major
> version number we should abandon the minor one).
> TLS 2017 strikes me as quite bad; we're certainly not planning to do a TLS
> 2018. I am strongly opposed to TLS 2017.
> 
> -Ekr
> 
> 
> On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner  wrote:
> 
> > At IETF 97, the chairs lead a discussion to resolve whether the WG should
> > rebrand TLS1.3 to something else.  Slides can be found @
> > https://www.ietf.org/proceedings/97/slides/slides-
> > 97-tls-rebranding-aka-pr612-01.pdf.
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
> > rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision
> > on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.

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

Re: [TLS] Draft 18 review : Extensions and message reuse

[Eric Rescorla]

On Tue, Nov 22, 2016 at 11:02 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:
>
> = Extensions and message reuse =
>
> We were sorry to find that some TLS 1.2 extensions were reused with a
> different meaning, or that some TLS 1.3 extensions were context
> dependent, which does not allow for a clear separation between the
> parsing step (which might lead to a decode_error alert) and the
> message validation step (which might lead to an invalid_parameter
> alert).  It is especially disappointing since the choice made for the
> ciphersuites is a very clean one.
>
> The first example of such a problem is the signature_scheme and
> signature_algorithms enums.  In practice, the signature_algorithm must
> contain information valid for TLS 1.2 and TLS 1.3, but the exact
> meaning is not the same in both cases.  It would be cleaner to have a
> new, separate extension called signature_scheme, defining the new
> enum.  This way, a TLS 1.2/1.3 client implementations would send both
> extensions.  We would spend 10 bytes on the wire, but it is not that
> important for the first message which can be kept reasonably long
> (and which is sometimes padded via the corresponding extension...)
>

We certainly could do this, but I don't think it's the right answer, for
two reasons:

1. From a protocol perspective, some of the things you could say with
signature_algorithms weren't coherent. For instance: I support ECDSA_SHA512
but only with P256 (via supported_curves). So it's actually a retroactive
improvement to TLS 1.2 to use the code points this way. NSS, at least
interprets these the same way in TLS 1.2 and TLS 1.3. I believe BoringSSL
does as well.

2. From an implementation perspective, it's easier to just have a single
external facing surface, which should be the more sensible one, namely
signature schemes.





> Another example is the key_share extension: it is in fact made of
> three different extensions, depending on the message where it is
> included.  It would be simpler for a (almost-)stateless parser* to
> either use three different extensions or to use the same content each
> time.  In the second case, the extension would each time consist of a
> list of (group + optional keyshare).  The advantages of such a unified
> keyshare extension would be:
>  - stateless parsing*
>  - no reuse of supported_groups which can be merged with key_share
>  - no more validation complexity since higher-level checks were
>already required (the groups sent by HRR did not came with a key
>share for example).
> The major con one might see is that the server can not advertise its
> supported groups in an encrypted manner anymore (since
> supported_groups is not used anymore).  However, we do believe
> simplifying the implementation is worth it.
>
> * Of course the parser still has to use the extension id to know how
>   to parse the value, but it would not need to have broader context
>   (the message where the extension is included).  In other words, we
>   would like select syntax in structs to only use local information.
>
> I can try and propose a PR for each extension if there is an interest
> in the WG.
>

It seems to me you are making two points here:

1. That it would be good to unify supported_groups and key_share
2. That we should use separate code points wherever extensions differ
between the messages they appear (this is far from the only one).

We've had some conversation about the first approach, which seems like kind
of a stylistic/taste issue whether to have the "I can do" and "here is" in
one
place or two, and on balance I think it's better to not change this at this
point
without a really compelling reason.

I can see the appeal of having one parser per extension ID, but it isn't
actually that much easier from an implementation perspective. You already
need a mapping table from extension ID to handler and that table
also needs to be able to detect common problems (e.g., extension reuse
or extensions appearing in the wrong place) and it's not hard at that
point to also have it point to message-specific parsers (this is how NSS
mostly works). ISTM that the alternative you propose would either result
in a proliferation of extensions (which confuses the matching rules)
or having extensions which are syntactically valid but not legal in
their context (e.g., >1 key share from the server). This pushes these
checks further away from the decoder, and makes things which would
otherwise be syntax errors (e.g., a "pre_shared_key" extension from
the server which contains keys) into semantic errors which require
explicit checks.

-Ekr


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

Re: [TLS] Draft 18 review : Message order

[Eric Rescorla]

On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

>
> = Message order =
>
> I believe the message P.27 section 4 is important, but not
> sufficient. As already expressed on the list, a formal automaton
> should be provided in the spec.
>
> I think Ekr said there was some work in progress in this area.  Is
> this a goal for the final specification?
>

Yes, I will put some sort of more complete state machine in the final spec
(probably in -19)

-Ekr


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

Re: [TLS] Draft 18 review : Signature in certificates

[Eric Rescorla]

On Tue, Nov 22, 2016 at 11:07 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = Signature in certificates =
>
> The two paragraphs in 4.4.1.2 P.56 starting with "All certificates"
> are very far from clear.  They require (MUST) some behaviour, which is
> later reformulated with an unless part.  I am not sure of the intent
> here, but we believe the current text should be rewritten to clearly
> express the intent of the WG.
>

We did try to make this clear, but maybe we failed.


My comprehension is that the server MUST use only signature schemes
> described in signature_algorithms, except for the following cases:
>  - for checking the signature in self-signed or trust anchors (since
>this check is useless, the trust coming from an out-of-band
>mechanism in this case)
>  - when the only available chains use signature scheme are not known
>to be supported by the client
>  - the case of SHA-1 is special
>

Yes, this seems accurate. If you would like to provide a PR that you think
makes this
clearer, that would be appreciated.

-Ekr


> The same confusion can be found in 4.4.2 P.59 ("If sent by a
> server...")
>
>
> Olivier Levillain
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 review : PSK and PSK Binder

[Eric Rescorla]

On Tue, Nov 22, 2016 at 11:06 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = PSK and PSK Binder =
>
> P.35 (4.2), it is specified that the pre_shared_key extension must be
> the last extension in the ClientHello, because of the way the PSK
> Binder is computed.  This seems very hackish and will most certainly
> lead to implementation errors.  However, I understand that it was not
> easy to propose a cleaner mechanism while keeping a common flow
> between *DHE and PSK modes.
>

I agree that this is piece is a little structurally unfortunate. It was a
compromise between a number of different imperatives and this ended
up being the best.


Yet, we would have preferred that PSK would not be MTI as stated in
> the end of the document (P.81, section 8.2).  In previous versions PSK
> and resumption was not MTI, so it might be logical to keep it this
> way.  Alternatively, we might propose a profile defining a simpler TLS
> subset.
>

I agree with this comment. I don't think the WG ever had consensus
to require PSK, it was just a side effect of trying to specify a list of
MTI extensions. I have filed https://github.com/tlswg/tls13-spec/issues/771
to
keep track of this.


Regarding the definition of the PSK Binder (P. 45 and 46, section
> 4.2.6.1), we found it very hard to read, since the binding value is
> said to be computed as the Finished message, but differently.  In
> particular, it would be useful to give the relevant information (I
> believe the Handshake Context is called transcript in this section,
> and it would be important to explicit the Hash to use), instead of
> implying it.  It would not take much space in the document, but it
> would ensure implementers know how to compute the binder.
>

OK. I will see if I can figure out how to rewrite this to make it clearer.

-Ekr


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

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

[Eric Rescorla]

On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez 
wrote:

> Being able to send supported_groups does allow a server to choose to make
> a tradeoff between an extra round trip on the current connection and its
> own group preferences. One example where a server might want to do this is
> where it believes that X25519 is likely a more future-proof group and would
> prefer that, but still believes the client's choice of P256 is suitable for
> this connection. Always requiring an extra round trip might end up being
> expensive depending on the situation so some servers might prefer to avoid
> sending an HRR for a slightly more preferred group.
>
> I think that requiring the client to maintain state from the
> supported_groups puts undue requirements on the client, since not all
> clients keep state between connections, and those that do usually only keep
> session state for resumption.
>

This matches my view as well.

I agree that the client should not be require to keep state. I do not
believe that the draft requires this, but if someone thinks otherwise,
please send a PR to fix.

-Ekr


>
> On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain <
> olivier.levill...@ssi.gouv.fr> wrote:
>
>> Hi list,
>>
>> I am sorry for the very late answer concerning draft 18, but we
>> (ANSSI) have several remarks after proof-reading the current
>> specification.
>>
>> We are sorry for the multiple long messages.
>>
>> If the WG is interested by some of our concerns/proposals, we would be
>> glad to propose some PRs.
>>
>>
>> = HRR and supported groups cache =
>>
>> In 4.2.4 (P.41), a server can send a supported_groups extension to
>> "update the client's view of its preference" in its ServerHello.
>> Since this behaviour is completely left to the client's discretion, it
>> does not seem a very relevant policy from the server: either the
>> server accepts one of the proposed groups, or it sends an HRR.  We do
>> not think the middle ground (OK for this group, but I would prefer
>> this other one) is relevant, so the sentence should be removed.
>>
>> Moreover, as far as I could understand, there is no indication in the
>> specification that a client should remember the preference of the
>> server in case it receives a HRR, which there would definitely make
>> sense.  Such text could go in 4.1.4.
>>
>> I can propose a PR for this point.
>>
>>
>> Olivier Levillain
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 review: Downgrade protection

[Eric Rescorla]

Hi Olivier,

Thanks for your comments. I do want this section to be clear.

It would be very helpful if you formatted this as a PR. That would make it
easier to understand the changes in this text.

Thanks,
-Ekr




On Tue, Nov 22, 2016 at 11:01 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = Donwgrade protection =
>
> On P.32 (section 4.1.3), the part about downgrade protection mechanism
> is not clear enough.  As I understand it, the modified server_random
> only occurs with a ServerHello indicating TLS 1.2 or below.  Moreover,
> a TLS 1.2 client should only abort the handshake with the TLS 1.1
> value, which is not clear in the explanation.  Finally, the
> ServerKeyExchange is only defined in TLS 1.2 or below, so it would be
> better to add some precision.  Here is a proposal to make these points
> more explicit:
>
>TLS 1.3 has a downgrade protection mechanism embedded in the server's
>random value.  TLS 1.3 server implementations MAY respond to a
>ClientHello indicating only support for TLS 1.2 or below with a
>ServerHello containing the appropriate version field.
>
>TLS 1.3 server implementations which respond with a TLS 1.2
>ServerHello, MUST set the last eight bytes of their Random value
>to the bytes:
>
>  44 4F 57 4E 47 52 44 01
>
>TLS 1.3 server implementations which respond with a ServerHello
>indicating support for TLS 1.1 or below SHOULD set the last
>eight bytes of their Random value to the bytes:
>
>  44 4F 57 4E 47 52 44 00
>
>TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check
>that the last eight octets are not equal to either of these values.
>TLS 1.2 clients SHOULD also check that the last eight bytes are not
>equal to the second value if the ServerHello indicates TLS 1.1 or
>below.  If a match is found, the client MUST abort the handshake
>with an "illegal_parameter" alert.  This mechanism provides limited
>protection against downgrade attacks over and above that provided
>by the Finished exchange: because the ServerKeyExchange, a message
>present in TLS 1.2 and below, includes a signature over both random
>values, it is not possible for an active attacker to modify the
>randoms without detection as long as ephemeral ciphers are used.
>It does not provide downgrade protection when static RSA is used.
>
> I can propose a PR if this makes sense to the WG.
>
>
> Olivier Levillain
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft 18 review : Signature in certificates

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= Signature in certificates =

The two paragraphs in 4.4.1.2 P.56 starting with "All certificates"
are very far from clear.  They require (MUST) some behaviour, which is
later reformulated with an unless part.  I am not sure of the intent
here, but we believe the current text should be rewritten to clearly
express the intent of the WG.

My comprehension is that the server MUST use only signature schemes
described in signature_algorithms, except for the following cases:
 - for checking the signature in self-signed or trust anchors (since
   this check is useless, the trust coming from an out-of-band
   mechanism in this case)
 - when the only available chains use signature scheme are not known
   to be supported by the client
 - the case of SHA-1 is special

The same confusion can be found in 4.4.2 P.59 ("If sent by a
server...")


Olivier Levillain

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

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

[Steven Valdez]

Being able to send supported_groups does allow a server to choose to make a
tradeoff between an extra round trip on the current connection and its own
group preferences. One example where a server might want to do this is
where it believes that X25519 is likely a more future-proof group and would
prefer that, but still believes the client's choice of P256 is suitable for
this connection. Always requiring an extra round trip might end up being
expensive depending on the situation so some servers might prefer to avoid
sending an HRR for a slightly more preferred group.

I think that requiring the client to maintain state from the
supported_groups puts undue requirements on the client, since not all
clients keep state between connections, and those that do usually only keep
session state for resumption.

On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = HRR and supported groups cache =
>
> In 4.2.4 (P.41), a server can send a supported_groups extension to
> "update the client's view of its preference" in its ServerHello.
> Since this behaviour is completely left to the client's discretion, it
> does not seem a very relevant policy from the server: either the
> server accepts one of the proposed groups, or it sends an HRR.  We do
> not think the middle ground (OK for this group, but I would prefer
> this other one) is relevant, so the sentence should be removed.
>
> Moreover, as far as I could understand, there is no indication in the
> specification that a client should remember the preference of the
> server in case it receives a HRR, which there would definitely make
> sense.  Such text could go in 4.1.4.
>
> I can propose a PR for this point.
>
>
> Olivier Levillain
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft 18 review : Minor remarks and typos

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= Minor remarks =

 - P.14 (section 2): "Everything after this phase is encrypted" =>
   "is protected" (since we also have integrity protection).

 - P.14 (section 2) and P.20 (section 2.3): the psk_key_exchange_modes
   extension is called "pre_shared_key_modes".

 - P.21 (section 2.3): Add a reference to the relevant section for
   "early exporter secret"?

 - P.41 and 42 (4.2.5): The fact that clients can send an empty
   client_shares vector is repeated 30 lines apart.  Is it really
   needed?

 - P.43 (section 4.2.5.2): during the description of ECDHE parameters
   with secp*,  the paragraph
 Although X9.62 supports multiple point formats, any given curve MUST
 specify only a single point format.  All curves currently specified
 in this document MUST only be used with the uncompressed point format
 (the format for all ECDH functions is considered uncompressed).
   seems to imply that all ECDHE points are uncompressed, which is not
   the case.  I would replace "All curves currently specified in this
   document" with "secp256r1, secp384r1 and secp521r1 curves".
   Similarly, I would remove the parenthesis.

 - P.44 (4.2.6): Unless I am mistaken, the identity field in the
   extension is the "ticket" (when using the older terminology).
   However, the term ticket is used in different places afterwards,
   without a proper definition.  It might make sense to add a word in
   the identities definition.

 - P.44 (4.2.6): Similarly, it would be clearer to say "externally
   established PSKs" (as in P.45) instead of "external tickets".

 - P.44 (4.2.6) Similarly, instead of saying that a binder must be
   given "for each PSK offered", it might be clearer to say "for each
   PSK identity offered".  (Sorry for th nitpick, but I believe it is
   important to be crystal clear in such a document).

 - P.46 (4.2.7): "Servers MUST NOT select a key exchange mode that is
   not listed by the client".  As I understand it, the server
   advertises its "selection" by adding the keyshare extension or not.
   It might be useful to add this precision if I am not mistaken.

 - P.48 (4.2.8): "the server MUST have accepted a PSK ciphersuite" =>
   since PSK ciphersuites do not exist anymore, should not it be "have
   accepted to use a PSK key exchange mode" or "have answered with a
   psk extension"?

 - P.53 (4.4): The Certificate message definition contains the
   following text: "Note that certificate-based client authentication
   is not available in the 0-RTT case." It might make more sense to
   move this text elsewhere in the section, and to explain it further:
   does it mean the 1-RTT following the early data must not contain a
   client authentication?

 - P.53 (4.4): What are "the pure 1-RTT cases"?

 - P.54 (4.4.1): Since the specification does not force the
   certificates to be ordered in the Certificate message anymore, what
   is the point of adding a SHOULD about the order?  On the other
   hand, the text might include the requirement that all intermediate
   AC are to be provided in the Certificate message.

 - P. 55 (4.4.1.1): Since it is now possible to add per-certificate
   extension, I believe status_request_v2 does not make any sense now.
   Should not it be clearer to deprecate it with TLS 1.3 and to force
   multiple OCSP stapling to be made exclusively with multiple
   status_request extensions (one for each cert)?

 - P.56 (4.4.1.2): The text "As servers MAY require the presence of
   the "server_name" extension, clients SHOULD send this extension,
   when applicable." should be moved elsewhere (e.g. when discussing
   ClientHello).

 - It is not clear whether a client can authenticate with a
   certificate when the server has chosen PSK authentication. P.49
   (4.3.2) states that "A server which is authenticating with a
   certificate can optionally request a certificate from the client."
   whereas 4.4.2 (P.59) states that "When used with
   non-certificate-based handshakes (e.g., PSK), the client's
   signature [in CertificateVerify] does not cover the server's
   certificate directly."  How should this be interpreted?

 - P.60 (4.4), it is said that "The key used to compute the finished
   message is computed from the Base key defined in Section 4.4 using
   HKDF", but we are *in* section 4.4, so there must be a mistake?

 - P.61 (4.5.1), it is said that "the resumption master secret depends
   on the client's second flight" but this is only true when the
   client authenticates itself with a certificate.  This point is
   related to a point sent by Ben Kaduk
   (https://www.ietf.org/mail-archive/web/tls/current/msg21829.html):
   "In section 4.5.1 we note that when client auth is not 

[TLS] Draft 18 review : Message order

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= Message order =

I believe the message P.27 section 4 is important, but not
sufficient. As already expressed on the list, a formal automaton
should be provided in the spec.

I think Ekr said there was some work in progress in this area.  Is
this a goal for the final specification?


Olivier Levillain

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

[TLS] Draft 18 review : Message splitting and interleaving

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= Message splitting and interleaving =

How to split and interleave subprotocols in TLS has not been clearly
specified in the past, and it would be useful to be crystal clear on
this point.

In the specification, the subject is first presented in 4.5 (P.61):
   Handshake messages sent after the handshake MUST NOT be interleaved
   with other record types.  That is, if a message is split over two or
   more handshake records, there MUST NOT be any other records between
   them.
But I am wondering why this text only concern "messages after the
handshake".  It should always be the case!

It is next present in section 4.5.3 (P.64):
   Handshake messages MUST NOT span key changes.  Because the
   ServerHello, Finished, and KeyUpdate messages signal a key change,
   upon receiving these messages a receiver MUST verify that the end of
   these messages aligns with a record boundary; if not, then it MUST
   terminate the connection with an "unexpected_message" alert.

And then in section 5 (mostly P.64 and P.65) plus a repetition P.69.


It is worth noting that this specific point was (at least partially)
the origin of several security issues:
 - the alert attack (https://www.mitls.org/pages/attacks/Alert);
 - Heartbleed (where OpenSSL answered with a fragmented record whereas
   it was not the spirit of the spec);
 - the OpenSSL Downgrade attack in 2014.

Some of this is covered in the current specification, but it might be
worth being even stricter:
 - regarding splitting/merging, they should be forbidden by default;
 - the default would apply to alerts (currently, the spec states that
   alerts MUST not be split, but they should not be merged either
   for simplicity's sake and since it is useless);
 - incidentally, the default behaviour would apply to Heartbeat, as
   was the intent of the specification;
 - ApplicationData should be considered as a stream with possibly
   0-length records
 - Handshake messages should either come as a sequence of multiple
   *entire* messages, or as a fraction of *one* message.  That is,
   the number of HS messages inside one record should either be a
   round number or strictly less than 1.

These constraints can be expressed in 5.1 and cover most of the
problematic cases.  They are easy to check and to enforce.


However, the problem of the OpenSSL Downgrade flaw (where the first
record containing the beginning of the ClientHello was cut before the
ClientHello.version field) will still stand, but there is no simple
way to fix this, since version negotiation can now happen anywhere in
the ClientHello extensions, so it might be impossible to enforce that
the client versions are sent in the first record.

I might volunteer some text if there is an interest of the WG.


Olivier Levillain

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

[TLS] Draft 18 review : 0-RTT

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= 0-RTT =

In 4.2.8 (P.47), the server receiving early_data "can behave in one of
two ways"... followed by three cases.  Beside the typo, the first case
could be phrased differently.  Actually, it reads

   -  Ignore the extension and return no response.  This indicates that
  the server has ignored any early data and an ordinary 1-RTT
  handshake is required.

Since an ordinary 1-RTT handshake will require the server to actually
send a response (the ServerHello), it might be better to put it this
way:

   -  Ignore the extension and return a standard 1-RTT ServerHello.
  This indicates that the server has ignored any early data and
  an ordinary 1-RTT handshake is required.


Olivier Levillain

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

[TLS] Draft 18 review : PSK and PSK Binder

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= PSK and PSK Binder =

P.35 (4.2), it is specified that the pre_shared_key extension must be
the last extension in the ClientHello, because of the way the PSK
Binder is computed.  This seems very hackish and will most certainly
lead to implementation errors.  However, I understand that it was not
easy to propose a cleaner mechanism while keeping a common flow
between *DHE and PSK modes.

Yet, we would have preferred that PSK would not be MTI as stated in
the end of the document (P.81, section 8.2).  In previous versions PSK
and resumption was not MTI, so it might be logical to keep it this
way.  Alternatively, we might propose a profile defining a simpler TLS
subset.

Regarding the definition of the PSK Binder (P. 45 and 46, section
4.2.6.1), we found it very hard to read, since the binding value is
said to be computed as the Finished message, but differently.  In
particular, it would be useful to give the relevant information (I
believe the Handshake Context is called transcript in this section,
and it would be important to explicit the Hash to use), instead of
implying it.  It would not take much space in the document, but it
would ensure implementers know how to compute the binder.


Olivier Levillain

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

[TLS] Draft 18 review : Extensions and message reuse

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= Extensions and message reuse =

We were sorry to find that some TLS 1.2 extensions were reused with a
different meaning, or that some TLS 1.3 extensions were context
dependent, which does not allow for a clear separation between the
parsing step (which might lead to a decode_error alert) and the
message validation step (which might lead to an invalid_parameter
alert).  It is especially disappointing since the choice made for the
ciphersuites is a very clean one.

The first example of such a problem is the signature_scheme and
signature_algorithms enums.  In practice, the signature_algorithm must
contain information valid for TLS 1.2 and TLS 1.3, but the exact
meaning is not the same in both cases.  It would be cleaner to have a
new, separate extension called signature_scheme, defining the new
enum.  This way, a TLS 1.2/1.3 client implementations would send both
extensions.  We would spend 10 bytes on the wire, but it is not that
important for the first message which can be kept reasonably long
(and which is sometimes padded via the corresponding extension...)

Another example is the key_share extension: it is in fact made of
three different extensions, depending on the message where it is
included.  It would be simpler for a (almost-)stateless parser* to
either use three different extensions or to use the same content each
time.  In the second case, the extension would each time consist of a
list of (group + optional keyshare).  The advantages of such a unified
keyshare extension would be:
 - stateless parsing*
 - no reuse of supported_groups which can be merged with key_share
 - no more validation complexity since higher-level checks were
   already required (the groups sent by HRR did not came with a key
   share for example).
The major con one might see is that the server can not advertise its
supported groups in an encrypted manner anymore (since
supported_groups is not used anymore).  However, we do believe
simplifying the implementation is worth it.

* Of course the parser still has to use the extension id to know how
  to parse the value, but it would not need to have broader context
  (the message where the extension is included).  In other words, we
  would like select syntax in structs to only use local information.

I can try and propose a PR for each extension if there is an interest
in the WG.


Olivier Levillain

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

[TLS] Draft 18 review: Downgrade protection

[Olivier Levillain]

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


= Donwgrade protection =

On P.32 (section 4.1.3), the part about downgrade protection mechanism
is not clear enough.  As I understand it, the modified server_random
only occurs with a ServerHello indicating TLS 1.2 or below.  Moreover,
a TLS 1.2 client should only abort the handshake with the TLS 1.1
value, which is not clear in the explanation.  Finally, the
ServerKeyExchange is only defined in TLS 1.2 or below, so it would be
better to add some precision.  Here is a proposal to make these points
more explicit:

   TLS 1.3 has a downgrade protection mechanism embedded in the server's
   random value.  TLS 1.3 server implementations MAY respond to a
   ClientHello indicating only support for TLS 1.2 or below with a
   ServerHello containing the appropriate version field.

   TLS 1.3 server implementations which respond with a TLS 1.2
   ServerHello, MUST set the last eight bytes of their Random value
   to the bytes:

 44 4F 57 4E 47 52 44 01

   TLS 1.3 server implementations which respond with a ServerHello
   indicating support for TLS 1.1 or below SHOULD set the last
   eight bytes of their Random value to the bytes:

 44 4F 57 4E 47 52 44 00

   TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check
   that the last eight octets are not equal to either of these values.
   TLS 1.2 clients SHOULD also check that the last eight bytes are not
   equal to the second value if the ServerHello indicates TLS 1.1 or
   below.  If a match is found, the client MUST abort the handshake
   with an "illegal_parameter" alert.  This mechanism provides limited
   protection against downgrade attacks over and above that provided
   by the Finished exchange: because the ServerKeyExchange, a message
   present in TLS 1.2 and below, includes a signature over both random
   values, it is not possible for an active attacker to modify the
   randoms without detection as long as ephemeral ciphers are used.
   It does not provide downgrade protection when static RSA is used.

I can propose a PR if this makes sense to the WG.


Olivier Levillain

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

Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard

[Sean Turner]

Seeing no objections I’ll get this process underway.

spt

> On Nov 15, 2016, at 20:10, Sean Turner  wrote:
> 
> Note that Russ pointed out during the meeting that even though we can use 
> this process a new RFC # will be minted at the end of the process.
> 
> spt
> 
>> On Nov 14, 2016, at 10:36, Sean Turner  wrote:
>> 
>> This email addresses the "Uplifting” bullet on slide 6 of the chair slides 
>> (https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-wg-chair-slides-00.pdf);
>>  this is entirely procedural (i.e., there’s really no technical ).
>> 
>> The cipher suite registry's new "WG recommended” column's “Y" values are 
>> being populated with cipher suites that are on standards track.  The notable 
>> exceptions are the EC-based AES-GCM ciphers defined in RFC 5289, which is an 
>> informational RFC.  This point is buried in an earlier version of 
>> draft-ietf-tls-tls13 and now in the soon to be 
>> draft-ietf-tls-iana-registry-updates (was 
>> draft-sandj-tls-iana-registry-updates); the complete list of the pet-TLS 1.3 
>> suites can be found here: 
>> https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01#section-6.
>> 
>> We can uplift RFC 5289 to PS from Informational with what essentially 
>> amounts to an IETF LC; we don't need a new draft (there's no errata).  We 
>> want to know if there are any objections to starting this process please 
>> post a message to the list by November 21st if you object (and why).
>> 
>> Please note the following:
>> 
>> -  This "action" is similar to what we're doing with 4492bis (it too is 
>> being moved to standards track) it's just that we can use this other process.
>> 
>> - RFC 7525, which was published through the UTA WG and is a BCP btw, already 
>> 2119-RECOMMENDs the ciphers.
>> 
>> - RFC 7540 (aka HTTP/2) MUSTs one of the RFC 5289 cipher suites.
>> 
>> spt
> 

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Daniel Migault]

I have a small preference for TLS 1.3.

On Tue, Nov 22, 2016 at 10:04 AM, Scott Schmit  wrote:

> On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote:
> > At IETF 97, the chairs lead a discussion to resolve whether the WG
> should rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-
> 97-tls-rebranding-aka-pr612-01.pdf.
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to
> not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this
> decision on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.
>
> I find it compelling that if we lived in an alternate universe where we
> had SSL 1996, TLS 1999, and a recently-published TLS 2006 or TLS 2008,
> there would have been a lot less inertia about switching to a later
> version.  I find is very optimistic given our history that we could
> manage two TLS versions in a year.  If that ever happened, though, we
> could do 2019.1 (as an increment) or 2019.11 (for the month).
>
> Barring that, I'd prefer TLS 4, since that gets us out of the version
> confusion swamp.  It would seem that almost nobody outside the security
> community understands the distinction between SSL and TLS; so if we call
> it TLS 4, we'll probably see it referred to as SSLv4.  And that wouldn't
> be horrible.  If we call it TLS 2 or TLS 2.0, some might refer to it as
> SSLv2.  That would obviously be very bad.
>
> While it's nice to able to look up information about TLS 1.3 drafts,
> most of that information is going to be inaccurate anyway, so I don't
> see that as a compelling reason to stick to it.  Granted, you have
> specific buzz for "TLS 1.3 is going to really improve things" but that's
> fairly easy to translate to "the new version of TLS is going to really
> improve things".
>
> The distinction between 2 vs 2.0 seems pretty minor.  SSLv2 is 2.0 and
> SSLv3 is 3.0, but few write it that way.
>
> Thus my ranked preference would be:
>
> TLS 2017 > TLS 4 > TLS 1.3 > TLS 2 or TLS 2.0
>
> But if I'm limited to a top choice from the list, then "Rebrand TLS 4"
>
> --
> Scott Schmit
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls