Subject: [Secdispatch] DANE IOT proposed outcome

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Nov 2020 11:54:59 +0100

Thanks to Shumon for presenting the DANE use case for IOT.

We discussed taking this to the [email-masked] <mailto:[email-masked]> list as there were a number of rather big open issues that people wanted to discuss.

We also discussed a non-WG forming BOF to look at, as Ted put it, the broader context for onboarding.  To give people a feel for the sort of related work that is available, here are a list of related activities:

draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a request/response mechanism that uses RFC 8366 vouchers to introduce devices and network infrastructure.
Intel’s SDO provides an application level introduction using vouchers as well.  This work has been taken up by the FIDO alliance.
The Wifi Alliance has Device Provisioning Protocol (DPP) which does not attach to a global name space prior to provisioning having occurred, but does represent a minimum case (just public keys).
draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for wired use, where DPP is focused on 802.11 networks.
There are a number of BRSKI related drafts by Owen as well, relating to cloud-based registrars.
There is also work by Michael Richardson and Peter Van Der Stock on constrained vouchers.  That work is taking place in ACE.

Understanding the landscape might help us understand where DANE fits in.

Regards,

Eliot

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 12:02:25 +0000

Thanks to Eliot for summarizing these.

I think the core concept of using DANE in IoT scenario is to get rid of certificates and PKIX. The solution of how to securely onboard the IoT devices and allocate the DNS domain name, both with and without initial certificates, is the key part to figure out.
If the IoT devices have no initial certificates, such as 802.1AR IDevID certificate, as their initial identity, then the BRSKI mechanism won’t be appropriate for these devices because BRSKI has a requirement of IDevID.
If the IoT devices have an IDevID certificate, I think it can still use BRSKI to onboard, but it won’t use EST to request a certificate any more, instead, it will apply for a DNS domain name by using some protocols.

That’s my preliminary thoughts, maybe not right.

Regards & Thanks!
Wei Pan

From: Secdispatch [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 6:55 PM
To: [email-masked]
Subject: [Secdispatch] DANE IOT proposed outcome

We discussed taking this to the [email-masked]<mailto:[email-masked]> list as there were a number of rather big open issues that people wanted to discuss.

  *   draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a request/response mechanism that uses RFC 8366 vouchers to introduce devices and network infrastructure.
  *   Intel’s SDO provides an application level introduction using vouchers as well.  This work has been taken up by the FIDO alliance.
  *   The Wifi Alliance has Device Provisioning Protocol (DPP) which does not attach to a global name space prior to provisioning having occurred, but does represent a minimum case (just public keys).
  *   draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for wired use, where DPP is focused on 802.11 networks.
  *   There are a number of BRSKI related drafts by Owen as well, relating to cloud-based registrars.
  *   There is also work by Michael Richardson and Peter Van Der Stock on constrained vouchers.  That work is taking place in ACE.

Regards,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Nov 2020 13:50:30 +0100

Hi Wei Pan,

I agree with you that there is a need for something that doesn’t require devices to have a full PKI built in.  But there needs to be something unique about the device that it can express and prove.  Also, we should separate out two problems:

Proving the peer to the device
Providing the device to the peer

Each has slightly different characteristics, especially when it comes to certificates.  Nobody should expect a huge cert store to be on a light weight client.  As was said in the chat, that is one thing that BRSKI solves.  But DPP/POK also solves it without certificates, but still requires at least a public/private key pair. Less than that I do not know how to work the problem.

Eliot

> On 16 Nov 2020, at 13:02, Panwei (William) <[email-masked]> wrote:
> 
> From: Secdispatch [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Eliot Lear
> To: [email-masked] <mailto:[email-masked]>
> --
> Iot-onboarding mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/iot-onboarding <https://www.ietf.org/mailman/listinfo/iot-onboarding>

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 14:46:16 +0000

Hi Eliot,

I understand there should be something unique to identity the device, it can be the certificate or public/private key pair or something else. I think the use of DANE in IoT scenario is to bind the device identity, i.e., the certificate or public key, to the DNS domain name.
In the BRSKI mechanism, after the device (pledge) and the network (registrar) authenticate each other, the device will apply for a local certificate from the network. What I mean is that the network may don’t need to have the PKI system to sign a certificate for the device, instead, the device can generate a key pair and the network allocates a DNS domain name to be related to the public key. So, after onboarding, the device will have a DANE TLSA record, therefore it can use that to authenticate itself to the server.
In the case without certificates, DPP/POK can solve the onboarding phase, then some other mechanisms may also be needed to provision the DNS domain name to the device.

Regards & Thanks!
Wei Pan

From: Iot-onboarding [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 8:51 PM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]; [email-masked]; Eliot Lear <lear=[email-masked]>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

Hi Wei Pan,

  *   Proving the peer to the device
  *   Providing the device to the peer

Eliot

On 16 Nov 2020, at 13:02, Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:

Regards & Thanks!
Wei Pan

From: Secdispatch [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 6:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Secdispatch] DANE IOT proposed outcome

Regards,

Eliot
--
Iot-onboarding mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 16 Nov 2020 15:47:15 +0100

Wrt. beyond thin device requiring at least a public key pair:

I thought there where also mechanisms by which the thin (IOT) device
might only have a unique symmetric key that is only shared with
some less constrained proxy ("in the cloud") that is supporting
the thin device in all more complex (crypto)  operations and avoid
the need for the thin device to support symmetric crypto - if thats
the component beyond its capabilities. 

Aka: Many ways to cut the cake. 

On Mon, Nov 16, 2020 at 01:50:30PM +0100, Eliot Lear wrote:
> Hi Wei Pan,
> 
> I agree with you that there is a need for something that doesn???t require devices to have a full PKI built in.  But there needs to be something unique about the device that it can express and prove.  Also, we should separate out two problems:
> 
> > If the IoT devices have no initial certificates, such as 802.1AR IDevID certificate, as their initial identity, then the BRSKI mechanism won???t be appropriate for these devices because BRSKI has a requirement of IDevID.
> > If the IoT devices have an IDevID certificate, I think it can still use BRSKI to onboard, but it won???t use EST to request a certificate any more, instead, it will apply for a DNS domain name by using some protocols.
> > 
> > That???s my preliminary thoughts, maybe not right.
> > 
> > Regards & Thanks!
> > Wei Pan
> > 
> > Intel???s SDO provides an application level introduction using vouchers as well.  This work has been taken up by the FIDO alliance.

> [email-masked]

-- 
---
[email-masked]

---

From: Shumon Huque <[email-masked]>
Date: Mon, 16 Nov 2020 10:13:47 -0500

Thanks Elliott for this summary.

We will start a discussion on the iot-onboarding list.

Shumon.

On Mon, Nov 16, 2020 at 5:55 AM Eliot Lear <lear=[email-masked]>
wrote:

> We discussed taking this to the [email-masked] list as there
> were a number of rather big open issues that people wanted to discuss.
>
> We also discussed a non-WG forming BOF to look at, as Ted put it, the
> broader context for onboarding.  To give people a feel for the sort of
> related work that is available, here are a list of related activities:
>
>
>    - draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a
>    request/response mechanism that uses RFC 8366 vouchers to introduce devices
>    and network infrastructure.
>    - Intel’s SDO provides an application level introduction using
>    vouchers as well.  This work has been taken up by the FIDO alliance.
>    - The Wifi Alliance has Device Provisioning Protocol (DPP) which does
>    not attach to a global name space prior to provisioning having occurred,
>    but does represent a minimum case (just public keys).
>    - draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for
>    wired use, where DPP is focused on 802.11 networks.
>    - There are a number of BRSKI related drafts by Owen as well, relating
>    to cloud-based registrars.
>    - There is also work by Michael Richardson and Peter Van Der Stock on
>    constrained vouchers.  That work is taking place in ACE.
>
>
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 15:17:16 +0000

Hi Toerless,

You're right, there're many ways to identify the device. But In the DANE client authentication case, the device's identity can only be the certificate or a public key pair, I think, because the DNS Server needs to store the public key hash values.
Except the initial identity, the device may be allocated a local identity after onboarding. So if the device has an initial identity of symmetric key, it has to be allocated a local identity of certificate or public key pair, then the local identity can be bound to a DNS domain name.

Regards & Thanks!
Wei Pan

-----Original Message-----
From: Secdispatch [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: Monday, November 16, 2020 10:47 PM
To: Eliot Lear <lear=[email-masked]>
Cc: [email-masked]; [email-masked]; Panwei (William) <[email-masked]>
Subject: Re: [Secdispatch] [Iot-onboarding] DANE IOT proposed outcome

I thought there where also mechanisms by which the thin (IOT) device might only have a unique symmetric key that is only shared with some less constrained proxy ("in the cloud") that is supporting the thin device in all more complex (crypto)  operations and avoid the need for the thin device to support symmetric crypto - if thats the component beyond its capabilities. 

On Mon, Nov 16, 2020 at 01:50:30PM +0100, Eliot Lear wrote:
> > From: Secdispatch [mailto:[email-masked] 
> > <mailto:[email-masked]>] On Behalf Of Eliot Lear
> > <https://www.ietf.org/mailman/listinfo/iot-onboarding>
> 

-- 
---
[email-masked]

---

From: Shumon Huque <[email-masked]>
Date: Mon, 16 Nov 2020 10:19:23 -0500

Hi Wei Pan,

I'll ask Ash (who is more plugged into the IOT ecosystem than I am) to
confirm .. but yes, our use case expects devices to have IDevID or some
other preconfigured unique value, so it should be possible to work with
BRSKI. For the DNS record format naming, we were initially looking at the
formats defined in draft-friel-pki-for-devices, specifically the LDevID
organization managed form, but have a slightly simpler form currently
specified in the draft.

Shumon.

On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <[email-masked]>
wrote:

> I think the core concept of using DANE in IoT scenario is to get rid of
> certificates and PKIX. The solution of how to securely onboard the IoT
> devices and allocate the DNS domain name, both with and without initial
> certificates, is the key part to figure out.
>
> If the IoT devices have no initial certificates, such as 802.1AR IDevID
> certificate, as their initial identity, then the BRSKI mechanism won’t be
> appropriate for these devices because BRSKI has a requirement of IDevID.
>
> If the IoT devices have an IDevID certificate, I think it can still use
> BRSKI to onboard, but it won’t use EST to request a certificate any more,
> instead, it will apply for a DNS domain name by using some protocols.
>
>
>
> *From:* Secdispatch [mailto:[email-masked]] *On Behalf Of *Eliot
> Lear
> *Sent:* Monday, November 16, 2020 6:55 PM
> *To:* [email-masked]
> *Subject:* [Secdispatch] DANE IOT proposed outcome
>
>
>

---

From: Shumon Huque <[email-masked]>
Date: Mon, 16 Nov 2020 10:31:30 -0500

On Mon, Nov 16, 2020 at 10:17 AM Panwei (William) <[email-masked]>
wrote:

> Hi Toerless,
>
> You're right, there're many ways to identify the device. But In the DANE
> client authentication case, the device's identity can only be the
> certificate or a public key pair, I think, because the DNS Server needs to
> store the public key hash values.
>

Correct. DANE records store X.509 certificates, their public key
components, or raw public keys -- most commonly hashes of them, but can
store the full certificate/key too.

Shumon.

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 15:51:34 +0000

Hi Shumon,

Thanks.

I was not so clear about how to use DANE before, mostly not clear about how to bind the device’s identity to the DNS domain name securely and automatically.
After Eliot’s explanation, I understand there are two parts: the device onboarding part and the DNS domain name provisioning part. And these two parts can be integrated, for example, when using BRSKI, the allocated DNS domain name can be bound to the LDevID.

Regards & Thanks!
Wei Pan

From: Shumon Huque [mailto:[email-masked]]
Sent: Monday, November 16, 2020 11:19 PM
To: Panwei (William) <[email-masked]>
Cc: Eliot Lear <lear=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Secdispatch] DANE IOT proposed outcome

Hi Wei Pan,

I'll ask Ash (who is more plugged into the IOT ecosystem than I am) to confirm .. but yes, our use case expects devices to have IDevID or some other preconfigured unique value, so it should be possible to work with BRSKI. For the DNS record format naming, we were initially looking at the formats defined in draft-friel-pki-for-devices, specifically the LDevID organization managed form, but have a slightly simpler form currently specified in the draft.

Shumon.

On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks to Eliot for summarizing these.

Regards & Thanks!
Wei Pan

From: Secdispatch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 6:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Secdispatch] DANE IOT proposed outcome

Regards,

Eliot
_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Ash Wilson <[email-masked]>
Date: Mon, 16 Nov 2020 11:13:05 -0800

Hi Wei Pan,
The process of bootstrapping the device's identity is outside the scope of
our drafts, but I completely agree that getting the bootstrapping process
right is important. We think that using DANE like this doesn't conflict
with other bootstrapping processes; it just adds a DNS-discoverable public
key to the identity of the device when it is provisioned.

One of the processes we are seeking to simplify is that of establishing
trust directly between devices in the field, both of which may have only
a keypair, and not the benefit of PKI that chains to a publicly trusted CA.
Supporting x.509 certificates is in the interest of providing broad
protocol compatibility (including the support of other adjacent standards
like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509).
By using TLSA for client auth, we allow devices with only a raw public key
in DNS, as well as devices with metadata-rich x.509 certificates, to
mutually authenticate without requiring the distribution of CA
certificates, just based on knowledge of the communicating peer's DNS name.

SIM/UICC identity providers may provision public keys in DNS, and leave a
record of the device's DNS name in the SIM card (likely to be found in the
certificate). This gives the device that receives the SIM card the ability
to do all the things that the PKI ecosystem supports now, with the
additional benefit of being able to mutually authenticate without the other
side of the handshake needing to possess and trust the CA certificate used
to sign the certificate that ships with the SIM card. Naming collisions are
prevented by binding the public key to the DNS name- only the possessor of
the private key corresponding to the TLSA record is the 'real' identity
holder.

In a similar fashion, device manufacturers may provision a DANE identity
for devices before they ship. These device identities may reside in a DNS
zone under the manufacturer's control, or the implementer may present the
device certificates in a DNS zone under the implementer's control. This
allows the identity to more naturally indicate the party responsible for
the device's behavior, and can make the mitigation of some types of network
abuse a little more straightforward.

On Mon, Nov 16, 2020 at 8:04 AM Shumon Huque <[email-masked]> wrote:

> On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <
> [email-masked]> wrote:
>
>>    - There are a number of BRSKI related drafts by Owen as well,
>>    relating to cloud-based registrars.

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 17 Nov 2020 01:54:54 +0000

Hi Ash,

Thanks for your clarifying. It’s clear to me now. Using DANE doesn’t conflict with other existing bootstrapping processes, but I feel some extensions may be needed to integrate.

Regards & Thanks!
Wei Pan

From: Ash Wilson [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:13 AM
To: Shumon Huque <[email-masked]>
Cc: Panwei (William) <[email-masked]>; [email-masked]; [email-masked]; Eliot Lear <lear=[email-masked]>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

Hi Wei Pan,
The process of bootstrapping the device's identity is outside the scope of our drafts, but I completely agree that getting the bootstrapping process right is important. We think that using DANE like this doesn't conflict with other bootstrapping processes; it just adds a DNS-discoverable public key to the identity of the device when it is provisioned.

One of the processes we are seeking to simplify is that of establishing trust directly between devices in the field, both of which may have only a keypair, and not the benefit of PKI that chains to a publicly trusted CA. Supporting x.509 certificates is in the interest of providing broad protocol compatibility (including the support of other adjacent standards like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509). By using TLSA for client auth, we allow devices with only a raw public key in DNS, as well as devices with metadata-rich x.509 certificates, to mutually authenticate without requiring the distribution of CA certificates, just based on knowledge of the communicating peer's DNS name.

SIM/UICC identity providers may provision public keys in DNS, and leave a record of the device's DNS name in the SIM card (likely to be found in the certificate). This gives the device that receives the SIM card the ability to do all the things that the PKI ecosystem supports now, with the additional benefit of being able to mutually authenticate without the other side of the handshake needing to possess and trust the CA certificate used to sign the certificate that ships with the SIM card. Naming collisions are prevented by binding the public key to the DNS name- only the possessor of the private key corresponding to the TLSA record is the 'real' identity holder.

In a similar fashion, device manufacturers may provision a DANE identity for devices before they ship. These device identities may reside in a DNS zone under the manufacturer's control, or the implementer may present the device certificates in a DNS zone under the implementer's control. This allows the identity to more naturally indicate the party responsible for the device's behavior, and can make the mitigation of some types of network abuse a little more straightforward.

On Mon, Nov 16, 2020 at 8:04 AM Shumon Huque <[email-masked]<mailto:[email-masked]>> wrote:
Hi Wei Pan,

Shumon.

Regards & Thanks!
Wei Pan

Regards,

Eliot

--
Ash Wilson | Technical Director
e: [email-masked]<mailto:[email-masked]>

[图像已被发件人删除。]

This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 03:36:06 -0500

Eliot Lear <lear=[email-masked]> wrote:
    > There is also work by Michael Richardson and Peter Van Der Stock on

Just to clarify: it's occuring in ANIMA right now.

{I also think that there is a lot of potential crossover between constrained
vouchers/BRSKI, CORE RD, and ASYNC-Enrollment.
And draft-selander-ace-ake-authz is a bytes-on-the-wire-incompatible,
but semantically identical version of BRSKI for ultra-contrained
environments.  It has no obvious home at this point.}

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 18 Nov 2020 12:10:08 +0000

Hi Eliot,

I find your use of the term peer confusing. Let me explain what I mean with this table on various terms for an EAP-TLS implementation:

   +-------------+---------------+-----------------+-------------------+
   |             | Device        | Gateway         | Server            |
   +-------------+---------------+-----------------+-------------------+
   | TLS         | Client        |                 | Server            |
   |             |               |                 |                   |
   | EAP/AAA     | Peer          | Authenticator   | EAP server/backend|
   |             |               |                 | auth server       |
   |             |               |                 |                   |
   | 802.1x      | Supplicant    | Authenticator   | Authentication    |
   |             |               |                 | server (AS)       |
   |             |               |                 |                   |
   | RADIUS      |               | Network access  | RADIUS server     |
   |             |               | server (NAS)    |                   |
   |             |               |                 |                   |
   | 802.11      | Station       | Access Point    |                   |
   +-------------+---------------+-----------------+-------------------+

Assuming email clients are able to render this ascii table correctly, I hope you understand that in some contexts, the device is the peer. When you say proving peer to device, and device to peer, I am unsure if you are referring to a server or a smartphone that acts as a companion device during bootstrapping.

I don't want to be the terminology police here asking people to be more cautious with the usage of terms. I also understand the reality that companies are often forced to do branding to look cool and perhaps improve chances of adoption.

Maybe as protocol engineers we can do somewhat better? I thought we already had too many terms for device: station/peer/client/supplicant. And then I saw the term pledge. Good luck trying to teach network security to new folks. No wonder many students I encounter now want to do AI or javascript but not low-level protocols. I am similarly not enthusiastic with usage of loose terms such as onboarding. At least in my study of several different systems including bluetooth/wi-fi/LWM2M: they principally follow the same terminology pattern: bootstrapping and authentication followed by provisioning/configuration. You could point me to OCF which uses onboarding but we don't have to make the same mistakes as another SDO.

--Mohit

On 11/16/20 2:50 PM, Eliot Lear wrote:
Hi Wei Pan,

Eliot

Regards & Thanks!
Wei Pan

Regards,

Eliot

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 18 Nov 2020 12:58:34 +0000

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

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?

--Mohit

On 11/16/20 9:13 PM, Ash Wilson wrote:
Hi Wei Pan,
The process of bootstrapping the device's identity is outside the scope of our drafts, but I completely agree that getting the bootstrapping process right is important. We think that using DANE like this doesn't conflict with other bootstrapping processes; it just adds a DNS-discoverable public key to the identity of the device when it is provisioned.

Shumon.

Regards & Thanks!
Wei Pan

Regards,

Eliot

[https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Nov 2020 14:03:30 +0100

Hi Mohit,

Your confusion is entirely understandable.  There the term means different things at different layers at this point.  Let me clarify:

In the general context, a peer is the other side of a connection.
In the EAP case, it’s the end device looking to be authenticated by an authenticator.

I think both uses are in context for this discussion… sadly.

Eliot

> On 18 Nov 2020, at 13:10, Mohit Sethi M <mohit.m.sethi=[email-masked] <mailto:mohit.m.sethi=[email-masked]>> wrote:
> 
> Hi Eliot,
> 
>>> On 16 Nov 2020, at 13:02, Panwei (William) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Nov 2020 09:09:54 -0500

On Wed, Nov 18, 2020 at 7:58 AM Mohit Sethi M <mohit.m.sethi=
[email-masked]> 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.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 18 Nov 2020 15:10:07 +0000

Hi Shumon,

Why won't the same issue apply to the IoT bootstrapping and the SIM card use case you described.  You would likely authenticate the server before revealing the client identity. And that cannot happen with DANE because of lack of initial Internet connectivity. If this is the case, then I fail to understand some of the excitement for use in IoT bootstrapping. Also, I am not sure if verifying DNSSEC signatures sent inside the proposed TLS extension would be simple and lightweight for IoT devices?

--Mohit

On 11/18/20 4:09 PM, Shumon Huque wrote:
On Wed, Nov 18, 2020 at 7:58 AM Mohit Sethi M <mohit.m.sethi=[email-masked]<mailto:[email-masked]>> 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).

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.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Nov 2020 10:48:10 -0500

I assume we can cover this at tomorrow's side meeting. I'm not fully
informed of the details of the network access authentication use case
specifically (I'm sure Ash will elaborate), but I assume there are other
possibilities for authenticating the server side in those environments,
such as straight PKIX auth with a pre-provisioned small trust anchor set.

Shumon.

On Wed, Nov 18, 2020 at 10:10 AM Mohit Sethi M <[email-masked]>
wrote:

> Hi Shumon,
>
> Why won't the same issue apply to the IoT bootstrapping and the SIM card
> use case you described.  You would likely authenticate the server before
> revealing the client identity. And that cannot happen with DANE because of
> lack of initial Internet connectivity. If this is the case, then I fail to
> understand some of the excitement for use in IoT bootstrapping. Also, I am
> not sure if verifying DNSSEC signatures sent inside the proposed TLS
> extension would be simple and lightweight for IoT devices?
>
> --Mohit
> 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).
>

---

From: Ash Wilson <[email-masked]>
Date: Wed, 18 Nov 2020 10:37:53 -0800

Hi Mohit,
  You are correct- using DANE for server authentication in use cases
without Internet connectivity (EAP-TLS, for instance) is challenging, and
may require other modifications to the process. It may make more sense for
the EAP-TLS use case to use another mechanism like the TLS DNSSEC chain
extension, or traditional PKI, to get around the lack of internet
connectivity for the server part of mutual authentication.

  Using DANE for client identity is expected to work well because the
authentication server typically has sufficient connectivity to interact
with DNS.

  These proposals aren't intended to replace any identity bootstrapping
protocols. Rather, they are intended to work in concert with existing
protocols to make public keys easily discoverable.

On Wed, Nov 18, 2020 at 7:48 AM Shumon Huque <[email-masked]> wrote:

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

--