Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share"

Hi Joe, My understanding is that we can't get rid of HRR unless we require clients to send a key_share for every key exchange group in the supported_groups extension. This would be a quite large overhead if the client wants to support lots of groups. Also HRR allows servers to request

Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors

+1 From: Richard Barnes Sent: Thursday, December 8, 2016 2:11 PM To: Eric Rescorla Cc: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors +1 On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla

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

+1 for “TLS 2017” for all the four reasons given in the proposal. My overall preference is TLS 2017 > TLS 4 > TLS 2 or 2.0 > TLS 1.3. Best, Xiaoyin From: D. J. Bernstein Sent: Sunday, November 20, 2016 7:56 PM To: tls@ietf.org Subject: Re: [TLS]

[TLS] What is the meaning of three dots

Hi, What is the meaning of three dots (…) in “ClientHello…ServerHello” and “ClientHello…Server Finished”, in section 7.1 Key Schedule? It seems this syntax is not defined in this document. [1] https://tlswg.github.io/tls13-spec/#rfc.section.7.1 Thank you! Best, Xiaoyin

Re: [TLS] supported_versions question

I think for question 1, it should ignore legacy_version, and select a version from supported_versions, because if a client only supports TLS 1.1 and TLS 1.3, in order to connect to pre-TLS1.3 server, it has to set legacy_version to TLS 1.1. I have no idea about questions 2 or 3. Best,

Re: [TLS] How should inability to access key revocation lists impact the TLS handshake?

But I think the problem is that there is no TLS alert for “revocation status inaccessible”. Best, Xiaoyin From: Salz, Rich Sent: Monday, October 24, 2016 2:15 PM To: Ryan Carboni; tls@ietf.org Subject: Re: [TLS] How

Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1 Xiaoyin From: Eric Rescorla Sent: Saturday, October 22, 2016 11:26 AM To: Stephen Farrell Cc: tls@ietf.org Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01 +1 This draft just codifies

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

Why does this draft normatively depend on TLS 1.3, even if the cipher suites defined in this draft use the old syntax, which TLS 1.3 no longer uses? Best, Xiaoyin From: Sean Turner Sent: Tuesday, October 18, 2016 9:19 AM To: Daniel

Re: [TLS] how close are we?

Not directly related to Rich's question, but will we settle the "TLS 1.3 -> TLS 2.0" discussion (PR #612) before WGLC? Or has this already been closed as "keeping the current name"? Best, Xiaoyin From: TLS

Re: [TLS] Industry Concerns about TLS 1.3

Andrew, Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks. Also, unlike SSL 3.0 – TLS 1.1, TLS 1.2 is not currently known to be weak or insecure, if properly implemented and not using insecure cipher suites. So in my opinion, it makes sense

Re: [TLS] Industry Concerns about TLS 1.3

Andrew, I don’t understand why your “choice is being removed”, because you can keep using TLS1.2 in your internal network, can’t you? Best, Xiaoyin From: BITS Security Sent: Friday, September 23, 2016 4:31 PM To: Salz, Rich;

Re: [TLS] Should TLS 1.3 servers send "signature_algorithms" extensions

Thank you for your explanation, Eric! Xiaoyin From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Monday, September 19, 2016 7:13 PM To: Xiaoyin Liu <xiaoyi...@outlook.com> Cc: tls@ietf.org Subject: Re: [TLS] Should TLS 1.3 servers send "signature_algorithms" extensions On Mon, S

[TLS] Should TLS 1.3 servers send "signature_algorithms" extensions

Hello, There seems to be a conflict in the TLS 1.3 spec on whether servers should send "signature_algorithms" extension or not. In section 4.2.2 Signature Algorithms, it says: Servers which are authenticating via a certificate MUST

Re: [TLS] Version negotiation, take two

I support this proposal. Xiaoyin From: David Benjamin Sent: Thursday, September 8, 2016 12:09 PM To: tls@ietf.org Subject: [TLS] Version negotiation, take two Hi folks, I'd like to revisit the question of version negotiation. EKR wrote up

Re: [TLS] TLS 1.3 -> TLS 2.0?

> From: Hubert Kario [mailto:hka...@redhat.com] > Sent: Wednesday, August 31, 2016 4:48 AM > To: Xiaoyin Liu <xiaoyi...@outlook.com> > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > > On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin Liu wrot

Re: [TLS] TLS 1.3 -> TLS 2.0?

> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario > Sent: Tuesday, August 30, 2016 4:14 PM > To: tls@ietf.org > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > > On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: > > * Keep the version ID as { 3,

Re: [TLS] TLS 1.3 -> TLS 2.0?

I support this change as long as there is no technical change (version ID remains 0x0304). Best, Xiaoyin From: Dave Garrett Sent: Tuesday, August 30, 2016 2:19 PM To: tls@ietf.org Subject: [TLS] TLS 1.3 -> TLS 2.0? I occasionally see

Re: [TLS] [Technical Errata Reported] RFC4492 (4783)

Why is the type editorial? According to [1], an editorial errata is "a spelling, grammar, punctuation, or syntax error that does not affect the technical meaning". Although the mistake in RFC4492 is clearly a typo, I think it does affect the technical meaning. So I would prefer to leave the

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

> Date: Fri, 3 Jun 2016 11:33:54 +0300 > From: ilariliusva...@welho.com > To: tls@ietf.org > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, > and server time] > > On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos wrote: > > > A simpler proposal is: