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

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Oct 2019 09:01:59 +0200 (CEST)

Schönwälder, Jürgen <[email-masked]> wrote:
> On Tue, Oct 01, 2019 at 12:38:08AM +0000, Kent Watsen wrote:
> > > 
> > > It may make sense to split by security protocol.
> > 
> > That would go some towards addressing Rich's concern.  Presumably we would have one module each for SSH  and TLS algorithms.  That said, to Rich's concern, there is a constant churn with them.  This churn concerns two activities:  the removal and addition of algorithms.  Both occur at protocol-version boundaries and, perhaps, other times as well.  This suggests to me that we could further refine the identities by protocol version, something like this:
> > 
> > In ietf-crypto-types:
> > 
> >     identity base-alg {}
> >     identity tls-alg { base "base-alg" }
> >     identity ssh-alg { base "base-alg" }
> > 
> > In ietf-tls-1.1-types:
> > 
> >     identity tls-1.1-alg { base "ct:tls-alg" }
> >     <a bunch of tls-1.1 identities here>
> > 
> > In ietf-tls-1.2-types:
> > 
> >     identity tls-1.2-alg { base "ct:tls-alg" }
> >     <a bunch of tls-1.2 identities here>
> > 
> > etc.
> > 
> > Updates only to the specific module would be needed.   The updates would only need to support new algorithms (not to remove support for legacy algorithms), as a different mechanism can be used for a server to advertise which algorithms it actually supports (on a more granular level).
> 
> I do not know whether this helps solving a problem or creates other
> problems as side effects. I think we have
> 
> a) a set of named algorithms that is changing over time
> b) a set of algorithms that are "blessed" for use a certain protocol
>    version (and the set may change over time)
> c) a set of algorithms supported by a protocol implementation (may change
>    with over time as well, i.e., with firmware updates)
> d) a set of algorithms configured to be used by a protocol implementation
>    (this is really what we want to get at)
> 
> Perhaps it is best to use identities for a)

Yes.

> and to expose the other
> sets via data leafs. I am not even sure exposing b) is required since
> b) is input to the protocol implementer and a client can (only)
> configure what is implemented anyway. I think c) could be exposed as
> config false data and d) is then config true data.

While I agree that this would probably work, I'm not convinced it is
required for now, to get this document done.  I think it can be ok to
declare this as out of scope for now.

> 
> > >> If advertising the specific identities is important, then a per identity if-feature could be used, although I'm not entirely sure that one feature per identity is really a great option either, but I think that this would be better than one per module.
> > > 
> > > Why not instead have a config false list of algorithms supported? Once
> > > we have solved this problem generically, this list may get deprecated.
> > 
> > I like this idea, but it means that ietf-crypto-types, where this config false list would be defined, presumably, would then have protocol accessible nodes and, to the point, may be odd for a "types" module to define.   Thoughts?  - a "config false" list okay?
> >
> 
> Such a config false list should go where the protocol specifics are
> defined. And it likely has to be protocol version specific for
> implementations that do support multiple versions of a security
> protocol.

Yes.

> I am generally not a fan of overloading names (or concepts in
> general). A YANG identity simply gives a name to something and a
> module simply puts a collection of named definitions into a common
> namespace. We should stay away from associating additional semantics
> with how an identity is named or how a module is named. If additional
> information is needed, model that additional information as data.

I agree.

/martin

>  
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>

---

From: tom petch <[email-masked]>
Date: Tue, 1 Oct 2019 10:58:31 +0000

<inline tp>

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 01, 2019 1:38 AM

> On Sep 27, 2019, at 1:46 PM, Schönwälder, Jürgen
<[email-masked]> wrote:
>
> On Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote:
>> I basically agree with what Martin is saying.
>
> So do I.

Hmmm...

>> Either one YANG module containing all of the crypto identities, or a
few YANG modules as previously suggested.
> It may make sense to split by security protocol.

That would go some towards addressing Rich's concern.  Presumably we
would have one module each for SSH  and TLS algorithms.  That said, to
Rich's concern, there is a constant churn with them.  This churn
concerns two activities:  the removal and addition of algorithms.  Both
occur at protocol-version boundaries and, perhaps, other times as well.
This suggests to me that we could further refine the identities by
protocol version, something like this:

In ietf-crypto-types:

    identity base-alg {}

In ietf-tls-1.1-types:

In ietf-tls-1.2-types:

etc.

<tp>

Kent

I am not sure how this can work. TLS has ciphersuites, rather than
algorithms, albeit which are combinations of algorithms.  Taking TLS1.2,
RFC5246, the ciphersuite is a combination of KEX, cipher, MAC leading to
e.g. TLS_RSA_WITH_AES_128_CBC_SHA
(which is MTI).

Separately, it has a signature algorithm and hash algorithm registry
which may be relevant, depending on the ciphersuite; these fit rather
better with the approach of this model.

Looking at the IANA registry of Transport Layer Security Cipher Suites
gives (to me) a good sense of how this has evolved from a base list for
TLS1.2 in RFC5246 with RFC5932 then adding Camellia, RFC5288 AES GCM
while RFC6289 updates the use of ECC, RFC5487 adds PSK with AES GCM,
RFC7251 adds AES-CCM, RFC7905 adds CHACHA20 and so on.  It is a long
list, extended many times.  TLS 1.3 is, so far, a shorter list.

So is your list of all the ciphersuites or multiple lists of the
algorithms that
underpin them?

It comes back to what is going to use this module. Whenever I see TLS, I
see ciphersuites first and foremost, not algorithms.

SSH is different, with KEX method names, authentication method names
encryption algorithm names and so on, with far fewer of them, a better
fit for this model.  But then SSH includes the Diffie-Hellman group in
the KEX name where TLS puts that in an extension - not the
ciphersuite -for TLS1.3 so the concept of a KEX is a bit different.

Tom Petch

Updates only to the specific module would be needed.   The updates would
only need to support new algorithms (not to remove support for legacy
algorithms), as a different mechanism can be used for a server to
advertise which algorithms it actually supports (on a more granular
level).

One issue not addressed is defining the identities for the algorithms
used to encrypt other keys in the keystore.   At least, neither SSH or
TLS are involved.  However, both the keystore and TLS use "ASN.1" and
so, somehow, the keystore may be encrypting with "TLS" (really ASN.1)
keys already... (requires more analysis)

>> If advertising the specific identities is important, then a per
identity if-feature could be used, although I'm not entirely sure that
one feature per identity is really a great option either, but I think
that this would be better than one per module.
> we have solved this problem generically, this list may get deprecated.

I like this idea, but it means that ietf-crypto-types, where this config
false list would be defined, presumably, would then have protocol
accessible nodes and, to the point, may be odd for a "types" module to
define.   Thoughts?  - a "config false" list okay?

Rich, does any of this line of thinking address your concern?  - or
maybe you liked more my previous idea of using IANA registries?

Kent // contributor

------------------------------------------------------------------------
--------

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Oct 2019 16:43:51 +0000

Thanks for pointing that out, Tom.  I was going to say something along these lines in a response to Juergen.    The net is that partitioning identities along protocol boundaries is misdirected.  We need to focus on the algorithms, not the cipher suites.  

Going back to the primary goal, we care about is how to use the "algorithm" field to identify the format of the public and private key fields.  To this end, the field could be called a "key-format" instead.   There is a secondary goal to pass an "algorithm" parameter into the 'generate-symmetric-key' and 'generate-asymmetric-key' actions, but maybe the problems can be separated?

In OpenSSL, the commands are:

1) `openssl genrsa -out rsa_private_key.pem 2048` creates an RSAPrivateKey (from RFC3447)
2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem` creates a SubjectPublicKeyInfo (from RFC5280)
3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` creates an ECPrivateKey (from RFC5915)
4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` creates a SubjectPublicKeyInfo (from RFC5280)

OpenSSH, the commands are:

1) `ssh-keygen -t rsa -b 4096 -C "[email-masked]"` creates an RSAPrivateKey (from RFC3447) and a proprietary public key file format.
2) `ssh-keygen -t ed25519 -b 4096 -C "[email-masked]"` creates an ECPrivateKey (from RFC5915) and a proprietary public key file format.
3) `ssh-keygen -e [-m RFC4716] -f <private-key-file>` exports the public key format described by RFC 4716.

Disclaimer: (2) is just a guess, based on (1), which I haven't tested myself yet.

In order to just identify the format, perhaps we use something like the following, which could be in ietf-crypto-types:  (Note I added OneSymmetricKey and OneAsymmetricKey formats as well.  That is, with this approach, it's not an "either-or" tradeoff, both can be defined.)

	    /*** all key format types ****/

	    identity key-format-base {}
	    identity public-key-format { base "key-format-base" }
	    identity private-key-format { base "key-format-base" }
	    identity symmetric-key-format { base "key-format-base" }

	    /**** for private keys ****/

	    identity rsa-private-key-format { // used by SSH and TLS
	        base "private-key-format";
	        description "An RSAPrivateKey (from RFC 3447).";
	    }

	    identity ec-private-key-format { // used by SSH and TLS
	        base "private-key-format";
	        description "An ECPrivateKey (from RFC 5915)";
	    }

	    identity one-asymmetric-key-format {
	        base "private-key-format";
	        description "A OneAsymmetricKey (from RFC 5958).";
	    } 

	    identity encrypted-private-key-format {
	        base "private-key-format";
	        description "A CMS EncryptedData structure (RFC 5652) containing a OneAsymmetricKey (RFC 5958).";
	     }

	    /**** for public keys ****/

	    identity ssh-public-key-format {
	        base "public-key-format";
	        description "The public key format described by RFC 4716.";
	    }

	    identity subject-public-key-info-format {
	        base "public-key-format";
	        description "A SubjectPublicKeyInfo (from RFC 5280).";
	    }

	    /**** for symmetric keys ****/

	    identity symmetric-key-format {
	        base "symmetric-key-format";
                description "An OctetString from ASN.1.";  
	            // Knowing that it is an "OctetString" isn't really helpful.  
	            // Knowing the length of the octet string would help a little, as it relates to the algorithm's block size
	            // We may want to only (for now) use "one-symmetric-key-format" for symmetric keys.
	            //     ^---- the usability issues Juergen mentioned before only applies to asymmetric keys?
	    }

	    identity one-symmetric-key-format {
	        base "symmetric-key-format";
	        description "A OneSymmetricKey (from RFC6031).";
	    } 

	    identity encrypted-symmetric-key-format {
	        base "symmetric-key-format";
	        description "A CMS EncryptedData structure (RFC 5652) containing an OneSymmetricKey (RFC 6031).";
	    } 

then, the public-key grouping might look like:

	  grouping public-key-grouping {
	    description
	      "A public key and its associated algorithm.";
	    leaf key-format {
	      nacm:default-deny-write;
	      type public-key-format;
	      mandatory true;
	      description "Identifies the format key's binary data value.";
	    }
	    leaf public-key {
	      nacm:default-deny-write;
	      type binary;
	      mandatory true;
	      description
	        "The binary value of the public key.  The interpretation
	         of the value is defined by the 'key-format' field.";
	    }
	  }

and the key-pair grouping might look like:

	  grouping asymmetric-key-pair-grouping {
	    description
	      "A private key and its associated public key.";
	    uses public-key-grouping;
	    choice private-key-type {
	      mandatory true;
	      description
	        "Choice between key types.";
	      leaf private-key {
	        nacm:default-deny-all;
	        type binary;
	        description
	          "The binary value of the private key.  The interpretation
	           of the value is defined by the 'key-format' field.";
	      }
	      leaf hidden-private-key {
	        nacm:default-deny-write;
	        type empty;
	        description
	          "A permanently hidden key.  How such keys are created
	           is outside the scope of this module.";
	      }
	    }
	  }

and the symmetric grouping might look like:

	  grouping symmetric-key-grouping {
	    description
	      "A symmetric key and algorithm.";
	    leaf key-format {
	      nacm:default-deny-write;
	      type public-key-format;
	      mandatory true;
	      description "Identifies the symmetric key's format.";
	    }
	    choice key-type {
	      mandatory true;
	      description
	        "Choice between key types.";
	      leaf key {
	        nacm:default-deny-all;
	        type binary;
	        description
	          "The binary value of the key.  The interpretation
	           of the value is defined by the 'key-format' field.";
	      }
	      leaf hidden-key {
	        nacm:default-deny-write;
	        type empty;
	        description
	          "A permanently hidden key.  How such keys are created
	           is outside the scope of this module.";
	      }
	    }
	  }

To put an end to this email, recall above it was said that the secondary goal is to pass an "algorithm" parameter into the 'generate-symmetric-key' and 'generate-asymmetric-key' actions (what kind of key to generate, right?).   Most of the above regards the key formats (not algorithms, though the OneSymmetricKey and OneAsymmetricKey structs do self-identify their algorithms).   I don't have an answer for this yet, but maybe we can mimic some aspect of the above for it?

Comments?

Kent // contributor

> On Oct 1, 2019, at 6:58 AM, tom petch <[email-masked]> wrote:
> 
> <inline tp>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Oct 2019 19:24:06 +0000

Yes there is churn.  We prefer to call it “change” or “evolution” :)  We hope that our protocols and data structures have enough flexibility, known as crypto agility, so that we don’t have to do huge revisions (as was the case when the MD5 digest was broken, for example).

Predicting the future is hard, especially for crypto, and this WG shouldn’t try.  That means that if the WG wants to keep current with best crypto practices, it probably should have smaller easy-to-revise documents rather than a single encyclopedia. (Apologies for repeating myself.) I don’t know the best way for this WG to do that as I am a netconf newbie.

As for the TLS ciphersuite evolution Tom mentioned, I can comment.  I am one of the TLS registry “expert reviewers.”  Yes, TLS 1.2 has dozens of algorithms supported; TLS 1.3 has eight.  While others may be added, they will be “not commended” (a new column added). My question is, do the ciphersuites matter in TLS configuration?  For most configurations that I see (including Akamai customers in my day job), it’s a random text string. Why does TLS configuration need more than a cert or two (RSA and ECDSA), the corresponding private keys, and a text list of ciphersuites?

Similarly, in my experiences with SSH, it’s about public keys (for hosts you talk to) and private keys.

I don’t think this WG needs to think about symmetric/bulk encryption keys at this point. Of course, I could be wrong and would love to understand why, if so.

---

From: tom petch <[email-masked]>
Date: Fri, 4 Oct 2019 12:10:10 +0000

<inline tp>

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Tuesday, October 01, 2019 5:43 PM

Thanks for pointing that out, Tom.  I was going to say something along
these lines in a response to Juergen.    The net is that partitioning
identities along protocol boundaries is misdirected.  We need to focus
on the algorithms, not the cipher suites.

Going back to the primary goal, we care about is how to use the
"algorithm" field to identify the format of the public and private key
fields.  To this end, the field could be called a "key-format" instead.
There is a secondary goal to pass an "algorithm" parameter into the
'generate-symmetric-key' and 'generate-asymmetric-key' actions, but
maybe the problems can be separated?

1) `openssl genrsa -out rsa_private_key.pem 2048` creates an
RSAPrivateKey (from RFC3447)
2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem`
creates a SubjectPublicKeyInfo (from RFC5280)
3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem`
creates an ECPrivateKey (from RFC5915)
4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem`
creates a SubjectPublicKeyInfo (from RFC5280)

1) `ssh-keygen -t rsa -b 4096 -C "[email-masked]"` creates an
RSAPrivateKey (from RFC3447) and a proprietary public key file format.
2) `ssh-keygen -t ed25519 -b 4096 -C "[email-masked]"` creates
an ECPrivateKey (from RFC5915) and a proprietary public key file format.
3) `ssh-keygen -e [-m RFC4716] -f <private-key-file>` exports the public
key format described by RFC 4716.

Disclaimer: (2) is just a guess, based on (1), which I haven't tested
myself yet.

In order to just identify the format, perhaps we use something like the
following, which could be in ietf-crypto-types:  (Note I added
OneSymmetricKey and OneAsymmetricKey formats as well.  That is, with
this approach, it's not an "either-or" tradeoff, both can be defined.)

    identity encrypted-private-key-format {
        base "private-key-format";
        description "A CMS EncryptedData structure (RFC 5652) containing
a OneAsymmetricKey (RFC 5958).";
     }

    identity symmetric-key-format {
        base "symmetric-key-format";
                description "An OctetString from ASN.1.";
            // Knowing that it is an "OctetString" isn't really helpful.
            // Knowing the length of the octet string would help a
little, as it relates to the algorithm's block size
            // We may want to only (for now) use
"one-symmetric-key-format" for symmetric keys.
            //     ^---- the usability issues Juergen mentioned before
only applies to asymmetric keys?
    }

    identity encrypted-symmetric-key-format {
        base "symmetric-key-format";
        description "A CMS EncryptedData structure (RFC 5652) containing
an OneSymmetricKey (RFC 6031).";
    }

To put an end to this email, recall above it was said that the secondary
goal is to pass an "algorithm" parameter into the
'generate-symmetric-key' and 'generate-asymmetric-key' actions (what
kind of key to generate, right?).   Most of the above regards the key
formats (not algorithms, though the OneSymmetricKey and OneAsymmetricKey
structs do self-identify their algorithms).   I don't have an answer for
this yet, but maybe we can mimic some aspect of the above for it?

Comments?

<tp>

Kent

I am still unclear about the big picture.  Are you saying that the other
lists of algorithms - MAC, hash, signature etc - would no longer be in
this I-D?  Or if they are still there, how are they going to be used

I see the role of what you list above in the client-server modules but
not a usage for the other lists.

Tom Petch

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Oct 2019 00:12:16 +0000

> To put an end to this email, recall above it was said that the secondary goal is to pass an "algorithm" parameter into the 'generate-symmetric-key' and 'generate-asymmetric-key' actions (what kind…

Answering myself here.  Having identities for "key formats" is useful and maybe helpfully decouples things, but how to support the actions remains open and yet critical to support.

Other than the "IANA registry" based proposal I gave Sep 27th (which I still think is pretty good), I don't see any other way to do this other than by going half-way back towards the old identity approach.  By "halfway", I mean to say that it doesn't define all the algorithm types, just the subset needed for our immediate needs.  So, either in addition or as a replacement to the identities for key formats, I think we should do the following:

   In ietf-crypto-types:

	   // define base identities so they can be referenced by groupings
	   identity asymmetric-key-algorithm;
	   identity symmetric-key-algorithm;
	   identity hash-algorithm;

   In ietf-asymmetric-key-algs.yang:

	    identity foo { base "asymmetric-key-algorithm" }
            ...
    
   In ietf-symmetric-key-algs.yang

	    identity bar { base "symmetric-key-algorithm" }
            ...

   In ietf-hash-algs.yang

	    identity baz { base "hash-algorithm" }
            ...

The three new modules can also be defined in the crypto-types draft, but by putting each algorithm-type into a distinct module, and by only defining a minimum number of algorithm types (there were many more before), it gets closer to what Rich wants, some modularity and no grand-unified solution.  On the downside, servers would have to implement more than one module and it we continue to need some config-false list of algorithms supported by the server (i.e., implementing the module != supporting all identities in the module).

Thoughts?  Is this something everyone can get behind? Do you think we should continue to have an identity for the "key format", or combine it with the definition of the "algorithm" node?

PS: Tom, I think this email answers your "big picture" question.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Oct 2019 12:22:08 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> 
> 
> > To put an end to this email, recall above it was said that the
> > secondary goal is to pass an "algorithm" parameter into the
> > formats (not algorithms, though the OneSymmetricKey and
> > OneAsymmetricKey structs do self-identify their algorithms).  I don't
> > have an answer for this yet, but maybe we can mimic some aspect of the
> > above for it?
> > 
> > Comments?
> 
> 
> Answering myself here.  Having identities for "key formats" is useful
> and maybe helpfully decouples things, but how to support the actions
> remains open and yet critical to support.
> 
> Other than the "IANA registry" based proposal I gave Sep 27th (which I
> still think is pretty good), I don't see any other way to do this
> other than by going half-way back towards the old identity approach.
> By "halfway", I mean to say that it doesn't define all the algorithm
> types, just the subset needed for our immediate needs.  So, either in
> addition or as a replacement to the identities for key formats, I
> think we should do the following:
> 
>    In ietf-crypto-types:
> 

But isn't this again a bit too much?  Why can't we define the base
identities in ietf-crypto-types, and then just the algs we need for
ssh in a separate module, and the algs we need for tls in another.

> The three new modules can also be defined in the crypto-types draft,
> but by putting each algorithm-type into a distinct module, and by only
> defining a minimum number of algorithm types (there were many more
> before), it gets closer to what Rich wants, some modularity and no
> grand-unified solution.  On the downside, servers would have to
> implement more than one module and it we continue to need some
> config-false list of algorithms supported by the server (i.e.,
> implementing the module != supporting all identities in the module).

Note that in general, a server may support one set of algs for node A
and another set of algs for node B.  So just listing the supported set
of identities is not sufficient.   Which is why I suggest (again) that
we don't try to solve this problem here and now.

/martin

> 
> Thoughts?  Is this something everyone can get behind? Do you think we
> should continue to have an identity for the "key format", or combine
> it with the definition of the "algorithm" node?
> 
>

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 8 Oct 2019 12:57:24 +0000

> 	    identity baz { base "hash-algorithm" }

I think there are

a) cryptographic algorithms (the primitives)
b) operating modes for symmetric algorithms etc.
c) combinations of a) and b) used by certain security protocols or
   sub-protocols (keyex vs data transfer)
d) key formats that are used together to combinations from b)

and we seem to sometimes confuse these things. If this is a proposal
for a), then fine. But these registries do not help much with b)-d),

I believe b) and d) tend to be security protocol specific (and may
even be security protocol version specific).

Looking at things from a management perspective, I assume the
relevance for configuration is d) to a).

Hence, I believe it makes sense to create a module with definitions
specifically needed for SSH and a module with definitions specifically
needed for TLS. (The SNMP model in RFCC 7407 has a several choices to
deal with different security "algorithms". This does not really matter
except that we also back then went for a security protocol specific
solution.)

/js

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 8 Oct 2019 13:02:22 +0000

> we don't try to solve this problem here and now.

We either solve the problem or we have to accept the people create
workarounds. It is no solution to say "we do this next year" over and
over again. And yes, the number of config false lists you need depends
on the number of config knobs.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Oct 2019 13:55:37 +0000

> except that we also back then went for a security protocol specific

An attempt to do this already exists.  Please look at:

  - https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14#section-5.3 <https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14#section-5.3>
  - https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-14#section-5.3 <https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-14#section-5.3>

As well as the tables in Section 5 in both drafts.

Admittedly, my co-authors decided to put this effort on hold while crypto-types issue is resolved, as the WG's focus is on the first three drafts of the client/server suite of drafts.   But the point is that the plan is to address the protocol-specific issue within these drafts.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Oct 2019 13:57:10 +0000

> on the number of config knobs.

Right, it doesn't help to pretend that implementing a module != supporting all identities in the module.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Oct 2019 14:07:32 +0000

> ssh in a separate module, and the algs we need for tls in another.

There is a difference between algorithm primitives and cipher suites
used by protocols.  In crypto types we're trying to define the primitives
that are used by the cipher suites.  Please see my email to Juergen
just now about how the "common" modules in the SSH and TLS
drafts portend to do this.  As for the primitives, the proposal above
is to keep the primitives down to the minimum needed for our 
immediate goals. 

>> it with the definition of the "algorithm" node?

Some of these questions are still hanging in the air...

Kent //

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Oct 2019 16:31:19 +0200 (CEST)

Schönwälder, Jürgen <[email-masked]> wrote:
> over again.

I didn't mean it that way.  I meant that there will be more details to
work out for this workaround, and I don't think it is (very) important
to have a workaround.  Hence my suggestion to leave this out for now.

/martin

> And yes, the number of config false lists you need depends