Re: [netconf] crypto-types fallback strategy

[tom petch <[e-mail]>]

<inline tp>

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

> On Sep 27, 2019, at 1:46 PM, Schönwälder, Jürgen
<[e-mail]> 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 {}
    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.

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


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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>