Re: [Secdispatch] Agenda time request: DANE for IOT security

[Eric Rescorla <[e-mail]>]

I have reviewed these drafts. While I don't have any strong opinions about
whether this technology is a good thing or not. I do have some thoughts
about
the TLS binding.

Overall, it's probably not good to try to do the same thing for TLS
1.3 and TLS 1.2, given the very different properties of client
authentication in the two protocols.

In 1.3 the right way to do this is for the server to indicate
willingness/desire for DANE information in the CertificateRequest and
the client to answer that in the Certificate. This will automatically
encrypt the contents of the extension without resort to ECH, just
as the client's cert is already encrypted.

TLS 1.2 doesn't support ECH nor does it it encrypt the certificate,
so it seems like ideally we would not support TLS 1.2 at all for
this extension. Is there a strong need for it?


Your encoding for the extension is not extensible because it does
not contain a length as well as a type.

   struct {
       NameType name_type;
       select (name_type) {
           case host_name: HostName;
       } name;
   } ClientName;

   ..

   struct {
       ClientName client_name_list<1..2^16-1>
   } ClientNameList;

The issue is that a receiver of an unknown type cannot properly skip
past it because it doesn't know the length (note that this is a known
problem in SNI as well). The correct approach is to have the ClientName
include a length field:

   struct {
       NameType name_type;
       uint16 length;               // NEW
       select (name_type) {
           case host_name: HostName;
       } name;
   } ClientName;

   struct {
       ClientName client_name_list<1..2^16-1>
   } ClientNameList;

Note that this will create a redundant length but that's basically
just the natural thing for TLS encoding and not really worth
fixing.

-Ekr












On Mon, Oct 12, 2020 at 5:53 PM Shumon Huque <[e-mail]> wrote:

> Dear SecDispatch chairs,
>
> We'd like to ask for a presentation slot at SecDispatch during
> IETF109 to talk about the use of DNS and DANE for IOT security.
> We'd cover the following set of topics:
>
> * DANE for TLS client authentication. Some proposed mechanisms
>   are described in the following drafts, which were originally
>   written a while back, and have recently been refreshed:
>     https://tools.ietf.org/html/draft-huque-dane-client-cert-04
>     https://tools.ietf.org/html/draft-huque-tls-dane-clientid-02
>
> * The use of DNS & DANE for certificate discovery.
>
> * Expanding the scope of DANE to cover the general use case of object
>   security (DANE currently offers TLSA for TLS channel authentication,
>   and SMIMEA for object security in email applications and email like
>   identities, so neither quite fit the bill in their current forms).
>
> Shumon Huque
> (with some colleagues working in the IOT security space).
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>