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 cons
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 @
> h
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,
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.
= D
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.
= E
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.
= H
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.
= P
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
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.
= M
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.
= M
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.
= M
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
p
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.
= S
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
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 bel
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
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
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
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 al
(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 resu
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.
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
On 23 November 2016 at 06:07, Olivier Levillain
wrote:
>
> 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 n
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 be
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 e
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
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
__
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.
>
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 allo
29 matches
Mail list logo
