Subject: Re: [netconf] crypto-types fallback strategy

From: Wang Haiguang <[email-masked]>
Date: Mon, 7 Oct 2019 08:30:02 +0000

Sorry to bring you all back to an email two weeks ago.

If I am not wrong, TLS 1.3 support to use raw public key between client and server.
I think TLS + Raw public key has been specified in RFC 7250 and later merge in RFC 8446 (TLS 1.3)

Best regards.

Haiguang

From: netconf [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Thursday, September 19, 2019 12:58 AM
To: Kent Watsen <[email-masked]>
Cc: [email-masked]; Rifaat Shekh-Yusef <[email-masked]>
Subject: Re: [netconf] crypto-types fallback strategy

Ø  The desire to use SubjectPublicKeyInfo is per tests (2) and (4) described here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netconf_ysukDdbCA0a70heF1a-5FldZNr4yE&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=2WjGA7HZCdgO3PuNIGcShf2is7JW06LCQdbjHnYFNs8&s=2a467Qepi3ZnOMc6bomXjp3ysTseF0EUXytuahNHZNw&e=>.

Those experiments do not matter.  TLS sends X509 certificates.  I am not aware of any protocol (and I don’t know all of them, of course) that sends raw public keys.  What protocols are you thinking of?

If you want to configure an HTTPS server using netconf/yang, you will need to give that server X509 certificates.

> don't understand the question.  I think your tip-toeing on a concern that a key should only be encrypted with a certain other key, if only the ensure that the strength of the encrypting key is not less than the key being encrypted.  Is this what you mean?

No, I was asking if “encrypted private key” is a separate thing from “plaintext private key.”

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Oct 2019 12:22:06 +0000

You are not wrong.  But public keys do not need to be encrypted or protected by other privacy means.  Private keys still do.  So “TLS with raw keys” does not change the security requirements compared to “TLS with certificates.”

My issue is that I do not think “TLS with raw keys” is used very much, and we do not have to support it in the first versions of these documents.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 7 Oct 2019 23:33:47 +0000

[CC-ing Henk, who lobbied for adding PSK and raw public keys to the trust store draft]

> My issue is that I do not think “TLS with raw keys” is used very much, and we do not have to support it in the first versions of these documents.

I'd like to get Henk's opinion on this.   

Henk, we're talking about modifying the tls-client-server draft to reference all private-key types in Keystore. Specifically, a PSK is effectively a /keystore:asymmetric-keys/asymmetric-key, and a raw public-key is effectively a /keystore:symmetric-keys/symmetric-key, right?  So the question is, when requesting the ability to authenticate TLS servers using those mechanisms, is there also a need to configure the private keys?

All, looking at ietf-tls-client.yang and ietf-tls-server.yang, adding the ability to configure the "private" half of a PSK or raw public key would be something like:

	OLD
	    container <client-identity or server-identity> {
	      uses ks:local-or-keystore-end-entity-cert-with-key-grouping;

	NEW
	    container <client-identity or server-identity> {
	      choice auth-type {
	         uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
	         uses ks:local-or-keystore-raw-public-key-grouping;
	         uses ks:local-or-keystore-pre-shared-key-grouping;

Kent