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

[Shumon Huque <[e-mail]>]

On Sat, Nov 14, 2020 at 8:28 PM Eric Rescorla <[e-mail]> wrote:

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

Thanks for the review!


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

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.



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

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.