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

From: "Bruckert, Leonie" <[email-masked]>
Date: Sun, 2 Sep 2018 13:30:45 +0000

We submitted an Internet Draft defining the usage of the Brainpool Curves for TLS 1.3.

We appreciate your comments.

Leonie

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet: Freitag, 31. August 2018 08:41
An: Merkle, Johannes; Manfred Lochter; Bruckert, Leonie
Betreff: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

A new version of I-D, draft-bruckert-brainpool-for-tls13-00.txt

has been successfully submitted by Leonie Bruckert and posted to the

IETF repository.

Name:                  draft-bruckert-brainpool-for-tls13

Revision:             00

Title:                     ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3

Document date:              2018-08-30

Group:                 Individual Submission

Pages:                  10

URL:            https://www.ietf.org/internet-drafts/draft-bruckert-brainpool-for-tls13-00.txt

Status:         https://datatracker.ietf.org/doc/draft-bruckert-brainpool-for-tls13/

Htmlized:       https://tools.ietf.org/html/draft-bruckert-brainpool-for-tls13-00

Htmlized:       https://datatracker.ietf.org/doc/html/draft-bruckert-brainpool-for-tls13

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.

Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Hanno Böck <[email-masked]>
Date: Sun, 2 Sep 2018 16:12:31 +0200

On Sun, 2 Sep 2018 13:30:45 +0000

> We submitted an Internet Draft defining the usage of the Brainpool

This draft doesn't contain any motivation on why anyone would want
this.

I believe it's not desirable to have a maximally large number of
algorithms specified for TLS. To the contrary, I believe it'd be good
to keep things as simple as possible and limit choices if there's no
good reason for them.
I don't think there's any reason for the brainpool curves except NIH
syndrome.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 2 Sep 2018 13:18:19 -0400

> to keep things as simple as possible and limit choices if there's no

Agreed.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Sep 2018 12:10:35 -0700

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12108

Leonie,

Can you say more about your intended outcome here? You don't need to
have an RFC in order to register these code points.

Are you hoping for WG acceptance, or are you just planning to register
on the basis of the I-D?

-Ekr

COMMENTS
S 1.
>      Brainpool Curves in earlier TLS versions.
>
>      The negotiation of ECC Brainpool Curves for key exchange according to
>      [RFC8446] requires the definition and assignment of additional
>      NamedGroup IDs.  This document specifies such values for three curves
>      from [RFC5639].

I think you want to state that this works for TLS 1.2 as well.

S 2.
>                   brainpoolP384r1(TBD2),
>                   brainpoolP512r1(TBD3)
>              } NamedGroup;
>
>      The encoding of ECDHE parameters as defined in section 4.2.8.2 of
>      [RFC8446] also applies to this document.

Which encoding? The structured encoding used for NIST curves or the
blob one used for the CFRG curves.

S 3.
>
>              enum {
>                   ecdsa_brainpoolP256r1_sha256(TBD4),
>                   ecdsa_brainpoolP384r1_sha384(TBD5),
>                   ecdsa_brainpoolP512r1_sha512(TBD6)
>              } SignatureScheme;

Just for completeness, you should state what these mean.

S 5.
>      y*Z^3) with the coefficient Z specified for that curve in [RFC5639],
>      in order to take advantage of an an efficient arithmetic based on the
>      twisted curve's special parameters (A = -3): although the twisted
>      curve itself offers the same level of security as the corresponding
>      random curve (through mathematical equivalence), an arithmetic based
>      on small curve parameters may be harder to protect against side-

"an arithmetic" isn't really idiomatic English.

S 6.2.
>         y_Z: the y-coordinate of the shared secret that results from
>         completion of the Diffie-Hellman computation
>
>      The field elements x_qA, y_qA, x_qB, y_qB, x_Z, y_Z are represented
>      as hexadecimal values using the FieldElement-to-OctetString
>      conversion method specified in [SEC1].

Do you want to give test vectors for the key share.

On Sun, Sep 2, 2018 at 6:30 AM, Bruckert, Leonie <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Bruckert, Leonie" <[email-masked]>
Date: Mon, 3 Sep 2018 07:20:12 +0000

Hi Eric,

We are aware that some working group members have a critical view of the Brainpool curves. Thus, we are not expecting working group consensus and standardization. We rather aim to register code points based on this I-D as a publicly available specification as required by IANA. Nevertheless, we appreciate constructive criticism.

Leonie

-----Ursprüngliche Nachricht-----
Von: Eric Rescorla [mailto:[email-masked]] 
Gesendet: Sonntag, 2. September 2018 21:11
An: Bruckert, Leonie
Cc: [email-masked]
Betreff: Re: [TLS] WG: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

Leonie,

-Ekr

COMMENTS
S 1.

S 2.

S 3.

S 5.

S 6.2.

On Sun, Sep 2, 2018 at 6:30 AM, Bruckert, Leonie <[email-masked]> wrote:

	Leonie

	-----Ursprüngliche Nachricht-----
	Von: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] 
	Gesendet: Freitag, 31. August 2018 08:41
	An: Merkle, Johannes; Manfred Lochter; Bruckert, Leonie
	Betreff: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

	IETF repository.

	Revision:             00

	Pages:                  10

	URL:            https://www.ietf.org/internet-drafts/draft-bruckert-brainpool-for-tls13-00.txt <https://www.ietf.org/internet-drafts/draft-bruckert-brainpool-for-tls13-00.txt> 

	Status:         https://datatracker.ietf.org/doc/draft-bruckert-brainpool-for-tls13/ <https://datatracker.ietf.org/doc/draft-bruckert-brainpool-for-tls13/> 

	Htmlized:       https://tools.ietf.org/html/draft-bruckert-brainpool-for-tls13-00 <https://tools.ietf.org/html/draft-bruckert-brainpool-for-tls13-00> 

	Htmlized:       https://datatracker.ietf.org/doc/html/draft-bruckert-brainpool-for-tls13 <https://datatracker.ietf.org/doc/html/draft-bruckert-brainpool-for-tls13> 

	Abstract:

	   protocol version 1.3.

	 

	The IETF Secretariat

	_______________________________________________
	TLS mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: "Bruckert, Leonie" <[email-masked]>
Date: Mon, 3 Sep 2018 08:25:13 +0000

We really don't want to restart the old debate. That's why we don't target standardization, but registration of code points only. Maybe you got this wrong.

RFC8447 adds a RECOMMENDED column to TLS Registries which allows for differentiating between entries explicitly recommended by an RFC and other entries based on a specification document only. We decided to choose the latter approach to register code points based on this I-D.  I wonder what's the purpose of this distinction if it is not offering a possibility for registering code points without full working group consensus.
 
Leonie

-----Ursprüngliche Nachricht-----
Von: TLS [mailto:[email-masked]] Im Auftrag von Viktor Dukhovni
Gesendet: Sonntag, 2. September 2018 19:18
An: [email-masked]
Betreff: Re: [TLS] WG: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

Agreed.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Sep 2018 13:18:33 +0200

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:
> 

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?

I also don't see the need to redefine curves from RFC 5639.
-- 
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

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Sep 2018 13:31:35 +0200

> > to keep things as simple as possible and limit choices if there's no

I'm against adding those curves to cryptographic libraries for the already 
stated reasons.

That being said, people asking for code point registrations shouldn't be 
forbidden from getting them – we may consider the reasons why they want them 
to be misguided or wrong – but we won't promote interoperability between 
implementations by forcing people to squat code points.
-- 
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

---

From: "Bruckert, Leonie" <[email-masked]>
Date: Mon, 3 Sep 2018 11:58:17 +0000

See my response inline.

-----Ursprüngliche Nachricht-----
Von: Hubert Kario [mailto:[email-masked]]
Gesendet: Montag, 3. September 2018 13:19
An: [email-masked]
Cc: Bruckert, Leonie
Betreff: Re: [TLS] WG: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

*** gpg4o | Die E-Mail wurde von einem unbekannten Schlüssel unterzeichnet: 92A8D1B801D2F5F5 ***

Yes! In section B.3.1.4 (https://tools.ietf.org/html/rfc8446#appendix-B.3.1.4) these numbers are deprecated.

For a previous discussion on the tls mailing list see https://www.ietf.org/mail-archive/web/tls/current/msg26646.html

I referred to RFC 5639 since it defines the Brainpool curve parameters first, without any relation to protocols.
--
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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Sep 2018 07:01:22 -0700

> missing the need for NamedGroup registrations – are the 26, 27 and 28

Yes. They are explicitly prohibited by the TLS 1.3 spec. See the previous
discussion on-list.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Sep 2018 16:21:53 +0200

On Monday, 3 September 2018 13:58:17 CEST Bruckert, Leonie wrote:
> Betreff: Re: [TLS] WG: New Version Notification for
> draft-bruckert-brainpool-for-tls13-00.txt

> missing the need for NamedGroup registrations – are the 26, 27
> and 28 tainted somehow?
> 
> Yes! In section B.3.1.4
> (https://tools.ietf.org/html/rfc8446#appendix-B.3.1.4) these numbers are
> deprecated.
>
> For a previous discussion on the tls mailing list see
> https://www.ietf.org/mail-archive/web/tls/current/msg26646.html

yes, I remember this thread, but I still don't see why those values can't be 
made acceptable for TLS 1.3. 

see those messages from that very thread:
https://www.ietf.org/mail-archive/web/tls/current/msg26667.html
https://www.ietf.org/mail-archive/web/tls/current/msg26670.html

> I referred to RFC 5639 since it defines the Brainpool curve parameters
> first, without any relation to protocols.

yes, but the actual values of curve parameters don't have to be in the draft, 
do they? this I-D doesn't completely obsolete RFC 5639 so there is no need to 
duplicate sections from the RFC, the I-D can just reference relevant sections 
from it

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Sep 2018 16:28:36 +0200

> Yes. They are explicitly prohibited by the TLS 1.3 spec. See the previous

well, implementations that receive them in TLS 1.3 still MUST ignore them, not 
abort connection, so I still think it will create less confusion to re-allow 
them than to re-assign new codepoints

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Sep 2018 08:15:24 -0700

On Mon, Sep 3, 2018 at 7:28 AM, Hubert Kario <[email-masked]> wrote:

> well, implementations that receive them in TLS 1.3 still MUST ignore them,

What text do you believe requires that?

> not

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.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Sep 2018 17:20:37 +0200

On Monday, 3 September 2018 17:15:24 CEST Eric Rescorla wrote:
> > > > >    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.
> > > > 

every one that deals with forward and backward compatibility... the whole 
GREASE I-D...
 
> one which actually supports Brainpool with TLS 1.3. Using new code

and why having that distinction is that important?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Sep 2018 08:30:15 -0700

On Mon, Sep 3, 2018 at 8:20 AM, Hubert Kario <[email-masked]> wrote:

> > > > > missing the need for NamedGroup registrations – are the 26, 27 and
> 28
> > > > > tainted
> > > > > somehow?
> > > >

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.

> 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.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Sep 2018 21:19:39 +0200

On Monday, 3 September 2018 17:30:15 CEST Eric Rescorla wrote:
> > > The issue is that it's not possible to distinguish a non-compliant TLS
> > 
> > 1.3
> > 

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Sep 2018 12:26:06 -0700

> it doesn't support them in TLS 1.2.

I don't think I agree with this. Why would that be the case?

Given that TLS 1.3 server usually implement both TLS 1.2 and TLS 1.3,
> having

We already have other special case code that enforces such rules. For
instance,
compression:

      For every TLS 1.3 ClientHello, this vector
      MUST contain exactly one byte, set to zero, which corresponds to
      the "null" compression method in prior versions of TLS.  If a
      TLS 1.3 ClientHello is received with any other value in this
      field, the server MUST abort the handshake with an
      "illegal_parameter" alert.  Note that TLS 1.3 servers might
      receive TLS 1.2 or prior ClientHellos which contain other
      compression methods and (if negotiating such a prior version) MUST
      follow the procedures for the appropriate prior version of TLS.

-Ekr

--

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 3 Sep 2018 20:59:31 +0000

I'm with EKR on this.

Regards,
Uri

Sent from my iPhone

> On Sep 3, 2018, at 15:27, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> We already have other special case code that enforces such rules. For instance,
> compression:
> 
>       For every TLS 1..3 ClientHello, this vector

---

From: Hubert Kario <[email-masked]>
Date: Tue, 04 Sep 2018 14:46:53 +0200

On Monday, 3 September 2018 21:26:06 CEST Eric Rescorla wrote:
> > > > > On Mon, Sep 3, 2018 at 7:28 AM, Hubert Kario <[email-masked]>
> > 
> > wrote:
> > > > > > > On Mon, Sep 3, 2018 at 4:18 AM, Hubert Kario <[email-masked]>
> > > > > > 
> > > > > > > wrote:
> > > > > > not
> > > > > > abort connection, so I still think it will create less confusion
> > > > > > to
> > > > > > re-allow
> > > > > 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
> > 
> > > for TLS 1.2 (the only kind you can write at this point), and
> > 
> > inappropriately
> > 
> > > If stack 2 receives a CH from stack 1 and responds by selecting a
> > 
> > Brainpool
> > 

because when servers don't do it we have "TLS version intolerance", "TLS 
extension intolerance" and so on.

From RFC 5246:

   If the list contains cipher
   suites the server does not recognize, support, or wish to use, the
   server MUST ignore those cipher suites, and process the remaining
   ones as usual.

and:

   the rules specified in [TLSEXT]
   require servers to ignore extensions they do not understand.

Not to mention the most explicit statement on this topic, from RFC 8446:

   Future extensions or additions to the protocol may define new values.
   Implementations need to be able to parse and ignore unknown values
   unless the definition of the field states otherwise.

In general, if the servers weren't required to ignore values they don't 
recognise, we would never be able to extend the value lists (be it 
SupportedGroups, or SignatureSchemes/SignatureAlgorithms).

>       follow the procedures for the appropriate prior version of TLS.

the difference is that we we don't want people to use compression in TLS 1.2, 
while brainpool in TLS 1.2 is just not recommended, not provably dangerous 
even when implemented correctly

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Sep 2018 06:32:19 -0700

On Tue, Sep 4, 2018 at 5:46 AM, Hubert Kario <[email-masked]> wrote:

> > > but while the server may abort the connection upon receiving them in
> TLS
> > > 1.3
> > > For one, and I think we can agree on that, is the server MUST ignore
> them
> > > if

This isn't an unknown value. It's a specifically prohibited value. Those
are different cases.

> > > code that does ignore them in TLS 1.2 and doesn't ignore them in TLS
> 1.3
> > > is
> > > only inviting bugs.
> >

That's reading stuff into the spec that's not there. They're both
prohibited from
being offered by TLS 1.3 clients.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Tue, 04 Sep 2018 16:09:16 +0200

On Tuesday, 4 September 2018 15:32:19 CEST Eric Rescorla wrote:
> > > > > On Mon, Sep 3, 2018 at 8:20 AM, Hubert Kario <[email-masked]>
> > 
> > wrote:
> > > > > > > > > On Mon, Sep 3, 2018 at 4:18 AM, Hubert Kario <
> > 
> > [email-masked]>
> > 
> > > > > > > > > wrote:
> > > > > > > > not
> > > > > > > > abort connection, so I still think it will create less
> > 
> > confusion
> > 
> > > > > > > > to
> > > > > > > > re-allow
> > > > > > > The issue is that it's not possible to distinguish a
> > 
> > non-compliant
> > 
> > > > TLS
> > > > 
> > > > > > 1.3
> > > > > > 
> > > > > > > one which actually supports Brainpool with TLS 1.3. Using new
> > 
> > code
> > 
> > > > > > > points makes this clear.
> > > > > > 
> > > > > 2. A stack which supports TLS 1.2 and TLS 1.3 and supports Brainpool
> > 
> > for
> > 
> > > > ah, yes, missed this case. That does taint all those codepoints for
> > > > TLS
> > > > 1.3
> > > > 

yes, that's why I said "doesn't support them in TLS 1.2.". I meant there the 
protocol in general, not a specific implementation (i.e. a server that 
implements TLS 1.2 as the highest version)

> being offered by TLS 1.3 clients.

Yes, it's not there, and I already agreed that it's acceptable for a server to 
abort when it sees such behaviour. But the reason why a behaviour (any 
behaviour) is prohibited influences the urgency of the fix (or presence of a 
check).
-- 
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