[TLS] Regarding the reference to SM ciphers

Hi Folks, It is in the hands of the designated experts and not the working group at large to determine what is an acceptable reference. Because of this we're asking participants to limit their discussion on this particular aspect of this topic. The registry policy for cipher suites is specif

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

Kepeng, It seems that this request is OBE (over taken by events) now that you’ve posted the referenced specifications to: https://github.com/alipay/tls13-sm-spec Cheers, spt > On Aug 19, 2019, at 05:38, Kepeng Li wrote: > > Hi WG chairs, > > Can we place the referenced documents in the TLS

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

Hi WG chairs, Can we place the referenced documents in the TLS WG GitHub? https://github.com/tlswg According to the discussion below, this can help people to read and understand the referenced specifications. Thanks, Kind Regards Kepeng 发件人: TLS 代表 "Blumenthal, Uri - 0553 -

Re: [TLS] On the difficulty of technical Mandarin (SM3 related)

Moving tls to bcc, and adding rfc-interest. (This is the kind of discussion that is likely to ignite a dumpster fire, and it's not specific to TLS work.) On Mon, Aug 19, 2019 at 11:05 AM Watson Ladd wrote: > I see no reason why English alone should be accepted for standards > documents we refere

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

On Mon, Aug 19, 2019 at 7:32 AM Paul Yang wrote: > > > On Aug 18, 2019, at 9:47 PM, Eric Rescorla wrote: > > The intent of the "Specification Required" requirement for registration is > that sufficient public information be available to allow an interoperable > implementation. Specifically, the

[TLS] On the difficulty of technical Mandarin (SM3 related)

Dear all, I see no reason why English alone should be accepted for standards documents we reference. French and German pose few difficulties, and one can always learn Russian. What I don't know is how difficult Mandarin is at a level to read a standards document. I expect the mechanics of using t

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

>  A side note: we will also upload the Markdown file of this draft into the >same git >  repository at https://github.com/alipay/tls13-sm-spec later to make it a totally     >  public involved progress. I think this is exactly what was needed/asked-for. Thank you! On Aug 19

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

> On Aug 18, 2019, at 9:47 PM, Eric Rescorla wrote: > > The intent of the "Specification Required" requirement for registration is > that sufficient public information be available to allow an interoperable > implementation. Specifically, the text says: > > https://tools.ietf.org/html/rfc812

[TLS] Last Call: (Issues and Requirements for SNI Encryption in TLS) to Informational RFC

The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Issues and Requirements for SNI Encryption in TLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

A side note: we will also upload the Markdown file of this draft into the same git repository at https://github.com/alipay/tls13-sm-spec later to make it a totally public involved progress. > On Aug 19, 2019, at 7:51 PM, Kepeng Li wrote: > > Currently

[TLS] Re： (offline) Re: Draft for SM cipher suites used in TLS1.3

Currently, we uploaded some of the referenced documents here: https://github.com/alipay/tls13-sm-spec @Rene, Parts 1 and 3 can be found in the link above. Hope it helps. Thanks, Kind Regards Kepeng -- 发件人：李克鹏(易深) 发送时间：2019年8月19日

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

Hi David, > On 16. Aug 2019, at 18:16, David Benjamin > wrote: > > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind wrote: > > >> One comment/question: I think I didn't quite understand what a client is > > >> supposed to do if the connection fails with use of greasing values...? > > >> The