Re: [Secdispatch] [Iot-onboarding] DANE IOT proposed outcome

[Shumon Huque <[e-mail]>]

On Wed, Nov 18, 2020 at 7:58 AM Mohit Sethi M <mohit.m.sethi=
[e-mail]> wrote:

> Hi Ash and Shumon,
>
> My understanding is that your solution is applicable to any scenario that
> uses client certificates. Obviously IoT might be one application area for
> this, but there are many other uses of client authentication with
> certificates.
>
Mohit - yes, there are certainly other application use cases and the
protocol is general purpose. Some SMTP transport security folks are
interested in this to give one example.

I don't have any strong opinions about whether this is useful or not. But
> it might be good to have a separate focused DANE working group for these
> drafts if there is strong demand for such a solution. Your presentation
> also highlighted your intention of defining new RRtype and/or expanding the
> scope of TLSA. These things (along with DANE light etc.) would require the
> input of DNS and TLS folks (in addition to the IoT requirements).
>

Yup, we will certainly need to get their input on this topic. I think I saw
a couple folks in the chat suggest resurrecting the DANE wg, which I'm open
to, but there was pushback too (I think more detailed discussion on list
was deemed necessary first).

Also, I didn't understand how would server authentication work? I probably
> did not listen to your presentation carefully enough but I suppose you
> cannot use DANE for server authentication in scenarios where the client
> device does not yet have Internet connectivity. So how would server
> authentication work in EAP-TLS/SIM card/IoT bootstrapping scenarios you
> discussed?
>

Yeah, the EAP-TLS case is trickier for DANE server authentication. There
are possible mechanisms though - the TLS DNSSEC chain extension (which
failed to gain consensus in the TLS WG a while back, but which will
probably be published through the IETF's independent stream) would provide
a way for the TLS server to deliver its DNS authentication chain inside the
TLS handshake, obviating the need for the client to perform DNS queries
prior to Internet connectivity. There are probably other solutions that
could be devised.

Shumon.