On Monday, 3 September 2018 17:15:24 CEST Eric Rescorla wrote: > On Mon, Sep 3, 2018 at 7:28 AM, Hubert Kario <hka...@redhat.com> wrote: > > On Monday, 3 September 2018 16:01:22 CEST Eric Rescorla wrote: > > > On Mon, Sep 3, 2018 at 4:18 AM, Hubert Kario <hka...@redhat.com> wrote: > > > > On Sunday, 2 September 2018 15:30:45 CEST Bruckert, Leonie wrote: > > > > > Htmlized: > > > > > https://tools.ietf.org/html/draft-bruckert-brainpool-for-tls13-00 > > > > > > > > > > Abstract: > > > > > This document specifies the use of several ECC Brainpool curves > > > > for > > > > > > > authentication and key exchange in the Transport Layer Security > > > > (TLS) > > > > > > > protocol version 1.3. > > > > > > > > So I understand why you need SignatureScheme registrations, but I'm > > > > completely > > > > missing the need for NamedGroup registrations – are the 26, 27 and 28 > > > > tainted > > > > somehow? > > > > > > Yes. They are explicitly prohibited by the TLS 1.3 spec. See the > > > previous > > > discussion on-list. > > > > well, implementations that receive them in TLS 1.3 still MUST ignore them, > > What text do you believe requires that?
every one that deals with forward and backward compatibility... the whole GREASE I-D... > > not > > abort connection, so I still think it will create less confusion to > > re-allow > > them than to re-assign new codepoints > > The issue is that it's not possible to distinguish a non-compliant TLS 1.3 > implementation which is inappropriately sending these code points from > one which actually supports Brainpool with TLS 1.3. Using new code > points makes this clear. and why having that distinction is that important? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
