Re: [TLS] WG: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

[Hubert Kario <[e-mail]>]

On Monday, 3 September 2018 17:15:24 CEST Eric Rescorla wrote:
> On Mon, Sep 3, 2018 at 7:28 AM, Hubert Kario <[e-mail]> wrote:
> > On Monday, 3 September 2018 16:01:22 CEST Eric Rescorla wrote:
> > > On Mon, Sep 3, 2018 at 4:18 AM, Hubert Kario <[e-mail]> 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