On Mon, Sep 3, 2018 at 8:20 AM, Hubert Kario <hka...@redhat.com> wrote:
> 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... > You're going to need a much more concrete reference than that. In general, if you receive a message that violates a MUST-level requirement, absent some very specific requirement that you ignore that violation, you're justified in aborting the connection. > > > 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? > Because otherwise you are risking interop problems: 1. A stack which supports TLS 1.2 and TLS 1.3 but only supports Brainpool for TLS 1.2 (the only kind you can write at this point), and inappropriately advertises the Brainpool curves in violation of the MUST above. 2. A stack which supports TLS 1.2 and TLS 1.3 and supports Brainpool for both (assuming that we adopt your proposal and reactivate these code points). If stack 2 receives a CH from stack 1 and responds by selecting a Brainpool curve, then there will be an interop issue when it sends an HRR [0] selecting the Brainpool curve. -Ekr [0] I'm assuming that the client doesn't offer a Brainpool KeyShare.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
