On Monday, 3 September 2018 17:30:15 CEST Eric Rescorla wrote: > 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: > > > > 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.
ah, yes, missed this case. That does taint all those codepoints for TLS 1.3 but while the server may abort the connection upon receiving them in TLS 1.3 CH (as it is violation of the MUST clause), I don't think it actually should abort it... For one, and I think we can agree on that, is the server MUST ignore them if it doesn't support them in TLS 1.2. Given that TLS 1.3 server usually implement both TLS 1.2 and TLS 1.3, having code that does ignore them in TLS 1.2 and doesn't ignore them in TLS 1.3 is only inviting bugs. -- 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
