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

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2020 17:28:11 -0800

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Shumon Huque <[email-masked]>
Date: Sat, 14 Nov 2020 22:41:15 -0500

> whether this technology is a good thing or not. I do have some thoughts

Thanks for the review!

> this extension. Is there a strong need for it?

Yeah, we're aware the privacy protections can only be achieved
with TLS 1.3.

My assumption (possibly mistaken) has been that we will need
to support deployed bases of both TLS 1.2 and 1.3.

However, since this protocol requires code changes in TLS stacks
anyway, perhaps we can mandate TLS 1.3 only, and modify the
protocol according to your suggestion (adding the new protocol
elements to CertificateRequest and Certificate and remove the
need for ECH).

I'll ponder and chat with some of the potential consumers of this
technology re: TLS 1.2/1.3.

> just the natural thing for TLS encoding and not really worth

Thanks for this suggestion.

It was modelled after SNI, and thus inherited that defect :)

At the moment, only one name type (and one instance of it)
is supported, so it doesn't really matter. But it is best to design
for extensibility, so I will plan to add the additional length field.

Shumon.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Nov 2020 15:35:27 +1100

Please DON'T design for extensibility. That is another aspect of the SNI design you don't want. If this fails, get a new extension point.

On Sun, Nov 15, 2020, at 14:41, Shumon Huque wrote:
> > whether this technology is a good thing or not. I do have some thoughts about
> > the TLS binding.
> 
> Thanks for the review!
> 
> >