Subject: [babel] DTLS Cached Info support in Babel

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 16 Jun 2021 22:04:34 +0000

Hi Babel,
On the YANG model, we're dealing with some questions around the parameters included to support the Cached Information Extension and Raw Public Keys in DTLS. This is briefly mentioned in 
https://datatracker.ietf.org/doc/html/rfc8968#appendix-A

Clearly (since they're only mentioned in an Appendix), they're highly optional.
But because it's there, we included the following items in the info model (which is now in AUTH48, so I want to avoid impacts to that):
 - the ability to express support for raw public keys, and configure certs that use raw public keys
 - a Boolean to indicate whether the extension should be "used" (per interface) 
 - an ordered list of preferred certificate types that is (supposed to be? can be?) used to populate the client_certificate_type and server_certificate_type extensions in the extended Client Hello message (per interface).

Maybe this was all overkill for something mentioned in an Appendix. But, anyway, here we are.

I think we're ok on the first item (raw public key support).
But for the other 2, there is some fuzziness.

Do any of the DTLS implementations support the cached info extension? If yes, do they programmatically decide whether they enable/use this by default on interfaces where DTLS is enabled? So whether this is enabled is just somehow decided by the implementation -- but we could allow that decision to be overridden by the user per interface? That would be consistent with the current Boolean. If none of the implementation support cached info are there any thoughts on how this might be done? There's an IESG objection to saying "Indicates whether the cached_info extension (see [RFC8968], Appendix A) is included in ClientHello and ServerHello packets. The extension is included if the value is "true"." So I'm thinking maybe it could say "Indicates whether use of the cached_info extension (see [RFC8968], Appendix A; see [RFC7924]) is enabled." Does this sound right?

The ordered list of preferred certificate types (per interface) is more of a problem It currently says:
"List of supported certificate types, in order of preference. The values MUST be among those listed in the babel-dtls-cert-types parameter. This list is used to populate the server_certificate_type extension (see [RFC8968], Appendix A) in a ClientHello. Values that are present in at least one instance in the babel-dtls-certs object of a referenced babel-dtls instance and that have a non-empty babel-cert-private-key will be used to populate the client_certificate_type extension in a ClientHello." Do any of the DTLS implementations support multiple types of certs? Do they implement sending the server_certificate_type and client_certificate_type in the ClientHello? If so, how do they populate these? If none implement this yet, any thoughts on how they might do it? Should we allow the programmatic default to be overridden per interface (or is that just too much complexity for a very optional feature)?

Thoughts appreciated.
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 19 Jun 2021 01:37:16 +0200

> https://datatracker.ietf.org/doc/html/rfc8968#appendix-A

[...]

> Do any of the DTLS implementations support the cached info extension?

It's definitely not supported by OpenSSL.  I haven't been able to find any
mention of it in the gnutls docs.

> Do any of the DTLS implementations support multiple types of certs?

Raw public keys are supported by gnutls but not by OpenSSL.

> Do they implement sending the server_certificate_type and
> client_certificate_type in the ClientHello? If so, how do they populate
> these?

As far as I understand, you set a key on the session structure, and the
behaviour will depend on the kind of key that you set.

> Should we allow the programmatic default to be overridden per interface
> (or is that just too much complexity for a very optional feature)?

I'm a little confused -- isn't the cert type implied by the value of
babel-dtls-cert-set-obj?

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 21 Jun 2021 14:19:07 +0000

Answering the last question...

> > On the YANG model, we're dealing with some questions around the
> parameters included to support the Cached Information Extension and Raw
> Public Keys in DTLS. This is briefly mentioned in
> > rfc8968 appendix-A
> 
> [...]
> 

The babel-dtls-cert-set-obj can contain multiple certs, and each cert has its cert type (so it's possible to have certs of all types). In the abstract TLS case, it's possible to envision a use case where the TLS client tells the server it supports the server providing X.509 and raw public key certs with X.509 preferred, and saying that it (the client) only has a raw public key. So the TLS specs allow for this. But in the specific Babel DTLS case, it would be rather illogical to configure the routers asymmetrically. Nonetheless, the flexibility exists in the info/data models. Which isn't necessarily a bad thing. It just means (IMO) these parameters are highly optional and we shouldn't put a lot of effort into perfecting them. Thx for the answers. That confirms what I was suspecting. - Barbara