[OPSAWG]Re: Request to review draft-ietf-opsawg-tacacs-tls13

[tirumal reddy]

On Tue, 7 May 2024 at 19:00,  wrote:

> Hi Tiru,
>
>
>
> Many thanks for the review. Forwarding it to the list, fwiw.
>
>
>
> I trust the authors will follow up. See one comment inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* tirumal reddy 
> *Envoyé :* mardi 7 mai 2024 15:17
> *À :* BOUCADAIR Mohamed INNOV/NET 
> *Cc :* draft-ietf-opsawg-tacacs-tl...@ietf.org
> *Objet :* Re: Request to review draft-ietf-opsawg-tacacs-tls13
>
>
>
>
>
> My comments on the use of TLS in the draft.
>
> 1.
>
>TACACS+ over TLS takes the protocol defined in [RFC8907], removes the
>option for MD5 obfuscation, and specifies the use of TLS (version 1.3
>or later) for transport using a new well-known default server port
>number.  The next sections provide further details and guidance.
>
> Comments> I suggest to use normative language that TACACS+ MUST use TLS
> 1.3. You may want to add that "It is expected that TACACS+ as described in
> this document will work with future versions of TLS."
>
> You may also want to say that earlier versions of TLS MUST NOT be used,
>
> 2. Implementations MUST support TLS 1.3 [RFC8446] and MAY permit TLS 1.3
>session resumption.  If resumption is supported, the resumption
>ticket_lifetime SHOULD be configurable, including a zero seconds
>lifetime.
>
> Comment> Session resumption is an in-built feature of TLS 1.3 and I don't
> see the need to use "MAY".
>
>
> 3. This document makes no cipher suite recommendations, but
>recommendations can be found in the TLS Cipher Suites section of the
>Section 4.3 of [RFC9325].
>
> Comment> I don't see a need to refer to RFC9325 (it is specific to (D)TLS
> 1.2).
>
> *[Med] My understand is that RFC covers 1.3 given that it says explicitly:
> *
>
>
>
> *This BCP applies to TLS 1.3, TLS 1.2, and earlier versions.*
>

The draft refers to RFC9325 in section 3.2,1 as follows:

   This document makes no cipher suite recommendations, but
   recommendations can be found in the TLS Cipher Suites section of the
   Section 4.3 of [RFC9325].

Comment> Section 4.3 of RFC9325 refers to Section 9.1 of TLS 1.3 [RFC8446]
for cipher suites. I don't see any use of referencing RFC9325 in this
section. Further, the ciphersuites currently mandated by RFC8446 may not be
recommended in future, it is better to follow the IANA registry,
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4;
it has a column which indicates whether a ciphersuite is recommended or
not. The draft may also want to refer to the warning in
https://datatracker.ietf.org/doc/html/rfc8447#section-8 (it explains that
recommended ciphersuites may be broken in future).

-Tiru


>
>
> *The tacacs+ spec has also the following:*
>
>
>
> *   Those implementing and deploying*
>
> *   Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3*
>
> *   outlined in [RFC9325], or its subsequent versions.*
>
>
>
> *   This document outlines additional restrictions permissible under*
>
> *   [RFC9325].  For example, any recommendations referring to TLS 1.2,*
>
> *  including the mandatory support, are not relevant for Secure TACACS+*
>
> *   as TLS 1.3 or above is mandated. *
>
>
>
>   RFC9325 is referred to in several places in the document and the same
> comment applies.
>
> 4. 3.2.2.1.  TLS Certificate Path Verification
>
>Implementations MUST support certificate Path verification as
>described in [RFC5280].
>
>Because a peer could be isolated from a remote peer's Certificate
>Authority (CA), implementations MUST support certificate chains
>(a.k.a. bundles or chains of trust), where the entire chain of the
>remote's certificate is stored on the local peer.  TLS Cached
>Information Extension [RFC7924] SHOULD be implemented.  This MAY be
>augmented with Raw Public Keys [RFC7250].
>
> Comment> Is it referring to PKIX-based authentication or use of local CA
> or both ? Please elaborate.
> Comment> How will the client identify the server identity (domain name) ?
> Comment> I am assuming the client MUST verify the chain of certificates up
> to a trust anchor as described in Section 6 of [RFC5280].  The client
> SHOULD use the default system or application trust anchors, unless
> otherwise configured.
> Comment> Why "SHOULD" and not use "MUST" ?
> Comment> What is the need to support raw public keys ?. The main security
> challenge with raw public keys is how to associate the public key with a
> specific entity and revocation (e.g., private key is compromised).
>
> 5.Device Identity based validation m

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-13.txt

[tirumal reddy]

This revision
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-13 addresses
comments from Paul Wouters (AD).

-Tiru

On Wed, 24 Jan 2024 at 11:05,  wrote:

> Internet-Draft draft-ietf-opsawg-mud-tls-13.txt is now available. It is a
> work
> item of the Operations and Management Area Working Group (OPSAWG) WG of the
> IETF.
>
>Title:   Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT
> Devices
>Authors: Tirumaleswar Reddy
> Dan Wing
> Blake Anderson
>Name:draft-ietf-opsawg-mud-tls-13.txt
>Pages:   34
>Dates:   2024-01-23
>
> Abstract:
>
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-13
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-tls-13
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review draft-ietf-opsawg-mud-tls-12

[tirumal reddy]

Hi Paul,

Thanks for the review. Please see inline

On Sat, 20 Jan 2024 at 03:55, Paul Wouters  wrote:

> Hi,
>
> I am assisting Rob Wilton with some documents, as so I am the (temporary)
> responsible AD for draft-ietf-opsawg-mud-tls
>
> I have reviewed this document and have a few questions and comments. I
> think the document generally is clear.
>
> I can see the MUD use case for using endpoint recognition based on TLS
> properties (eg SNI, ClientHello in TLS 1.2, IP addresses and hostnames. I
> don't have as much faith in using MUD to identify rogue TLS connections
> based on their cryptographic or extension properties (eg ciphersuites). I
> would expect that ciphersuites would change, and that an IoT device would
> mostly only implement the one or two ciphersuites (and TLS extensions) it
> supports. Malware would have to ensure their C can talk all kinds of
> ciphersuites and extensions to allow all kinds of limited implementation
> IoT devices to connect to it. So I don't think those parts would likely to
> trigger a MUD security rule. But there is no harm in trying.
>

In our research, TLS properties can be used to identify benign and malware
flows. The results with Google Home and several malware families were
presented in T2TRG few years back, please see
https://datatracker.ietf.org/meeting/interim-2020-t2trg-01/materials/slides-interim-2020-t2trg-01-sessa-mud-dtls-profiles-for-iot-devices-00.pdf
for
details.


>
> Some specific questions:
>
>+--rw supported-tls-version*ianatp:tls-version
>   +--rw supported-dtls-version*   ianatp:dtls-version
>   +--rw cipher-suite* [cipher hash]
>   |  +--rw cipherianatp:cipher-algorithm
>   |  +--rw hash  ianatp:hash-algorithm
>   +--rw extension-type*
>   |   ianatp:extension-type
>   +--rw accept-list-ta-cert*
>   |   ct:trust-anchor-cert-cms
>   +--rw psk-key-exchange-mode*
>   |   ianatp:psk-key-exchange-mode
>   |   {tls13 or dtls13}?
>   +--rw supported-groups*
>   |   ianatp:supported-group
>
> It seems for TLS 1.3, "cipher" is the AEAD cipher. But for TLS 1.2
> this could be a non-AEAD cipher in a ciphersuite that includes the
> DH part in the ciphersuite. How would those be expressed? I
> know the documents point to advise to use only AEAD for TLS 1.2,
> but that does not mean it does not need to be able to express it here?
> eg how to express the TLS 1.2 ciphersuit TLS_DH_DSS_WITH_AES_128_CBC_SHA
> in this model? See also the "supported groups" entry (I assume this is
> about DH groups?)
>

Good catch, modified the YANG module to use uint16 to represent the cipher
suite to match the TLS IANA registry of cipher suite (that includes
non-AEAD ciphers). The supported-group in the YANG module matches TLS
supported groups registry, see
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
.


>
>   +--rw application-protocol*
>
> Is ALPN meant here?
>

Yes, please see Section 5.3 of the draft

  typedef application-protocol {
type string;
description
  "Application-Layer Protocol Negotiation (ALPN) Protocol ID
   registry as defined in Section 6 of RFC7301.";
  }


> Perhaps using "alpn" instead of "application-protocol"
> would be clearer? But I'm okay with whatever the WG / authors deem better.
>
> Section 9:
>
> An attacker cannot read the MUD URL and identify the IoT device.
>
> Should this be "so that an attacker ." ?
>
> It could use a more inclusive term for "man-in-the-middle", eg "on path
> attacker" or "machine-in-the-middle"
>

Agreed, updated text as follows:

   The MUD URL MUST be encrypted and shared only with the authorized
components in the
   network (see Section 1.5 and Section 1.8 of [RFC8520]) so that an on-
   path attacker cannot read the MUD URL and identify the IoT device.

Cheers,
-Tiru


>
> Once the above questions are answered and possibly resolved with new text,
> I think the document is ready for IETF LC.
>
> Paul
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption call for IPFIX

[tirumal reddy]

I support adoption of all three drafts.

-Tiru

On Tue, 6 Jun 2023 at 10:49, Tianran Zhou  wrote:

> Hi WG,
>
>
>
> As we agreed on IETF 116, this mail starts a two weeks working group
> adoption call for the following three related drafts:
>
>
>
> Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry
>
> https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/
>
>
>
> Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements
>
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/
>
>
>
> Export of UDP Options Information in IP Flow Information Export (IPFIX)
>
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/
>
>
>
> Please send your support or objection to the list.
>
> Any comments are welcome.
>
>
>
> This call will be end on June 20.
>
>
>
> Cheers,
>
> Tianran, as cochair
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR poll for 3 IPFIX drafts

[tirumal reddy]

No, I'm not aware of any IPR that applies to these drafts.

-Tiru

On Wed, 7 Jun 2023 at 13:52,  wrote:

> Hi Tianran, all,
>
>
>
> (ccing co-authors and interested contributors, fwiw)
>
>
>
> No, I'm not aware of any IPR that applies to these drafts.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG  *De la part de* Tianran Zhou
> *Envoyé :* mardi 6 juin 2023 08:12
> *À :* opsawg 
> *Cc :* opsawg-chairs 
> *Objet :* [OPSAWG] IPR poll for 3 IPFIX drafts
>
>
>
> Hi WG,
>
>
>
> Accompany with the adoption call, this mail starts an IPR poll for the
> following drafts.
>
> https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/
>
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/
>
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/
>
>
>
> The authors, contributors and the WG, please state either:
>
>
>
> "No, I'm not aware of any IPR that applies to these drafts."
>
> Or
>
> "Yes, I'm aware of IPR that applies to these drafts."
>
>
>
> If you are aware of IPR, please indicate whether or not this has been
> disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179).
>
>
>
> Cheers,
>
> Tianran
>
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element

[tirumal reddy]

On Wed, 22 Feb 2023 at 13:43,  wrote:

> Hi Joe, all,
>
>
>
> draft draft-ietf-opsawg-rfc7125-update-00 is now online.
>
>
>
> Please find below an update to this point mentioned in the call for
> adoption:
>
> **
>
> · Edit a second draft to “clean” other entries in registry. This
> document is intended to include only simple fixes and which do not require
> updating existing RFCs. The candidate list of these proposed fixes can be
> seen at
> https://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html.
> New IEs, if needed, will be moved to a separate document.
> simple-ipfix-fixes may or may not be published as an RFC.”
>
> **
>
>
>
> # Simple fixes
>
>
>
> We edited many iterations of draft-boucla-opsawg-ipfix-fixes to address
> the comments received in the list. This draft is scoped to cover simple
> fixes. We think that this version is stable enough.
>
>
>
> # Implementing many of these fixes requires an IETF consensus
>
>
>
> After digging into base specs, it appears that touching entries that were
> settled via IETF can’t be touched directly by DEs (RFC7013):
>
>
>
> This process should not in any way be construed as allowing the
>
> IE-DOCTORS to overrule IETF consensus.  Specifically, Information
>
> Elements in the IANA IE registry that were added with IETF
>
> consensus require IETF consensus for revision or deprecation.
>
>
>
> This means that we will need to publish draft-boucla-opsawg-ipfix-fixes as
> an RFC as well so that fixes can be implemented.
>
>
>
> # New IEs to fix the issues identified in draft-boucla-opsawg-ipfix-fixes
>
>
>
> As part of the analysis, we found that new IEs are needed to fix major
> issues with existing ones. These new IEs are now specified in
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/
> as per the initial scope for the simple-fixes I-D.
>
>
>
> We explored in previous versions of draft-boucla-opsawg-ipfix-fixes an
> approach to build on existing IEs, but that approach implies that ordering
> of the IEs is important. I liked personally that alternate design but it
> appears that it is problematic given that RFC7011 only says SHOULD not a
> MUST for ordering:
>
>
>
>If an Information Element is required more than once in a Template,
>
>the different occurrences of this Information Element SHOULD follow
>
>the logical order of their treatments by the Metering Process.
>
>
>
> After discussing with Benoît, and rather than using
> rfc6313.html#section-4.4.6, we decided to use a property that is provided
> in the base spec: rfc7011.html#section-6.2.
>
>
>
> This I-D can be used to interact with TCP and 6man WGs.
>
>
>
> # UDP surplus area
>
>
>
> Together with Tiru, we edited
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/
> to cover UDP options. The design is similar to the one we are proposing for
> TCP options.
>
>
>
> I think that it is reasonable to consider adoption for these three I-Ds as
> a set.
>

Yes, it will be good to see all the three drafts progress.

-Tiru


>
>
> I let Benoît and Tiru further comment as appropriate.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG  *De la part de* Joe Clarke
> (jclarke)
> *Envoyé :* mardi 21 février 2023 17:56
> *À :* Joe Clarke (jclarke) ;
> opsawg@ietf.org
> *Objet :* Re: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits
> IP Flow Information Export (IPFIX) Information Element
>
>
>
> Sorry, all.  I was out of the office since late Jan, and I forgot to close
> this out.
>
>
>
> There has been considerable support for this work to be adopted with Paul
> Aitken dissenting.  However, in looking at the follow-up from Benoit,
> perhaps this issue is resolved.  Nonetheless, there is enough to call rough
> consensus and adopt this work to move it forward.
>
>
>
> Authors, please rename this draft draft-ietf-opsawg-rfc7125-update-00 –
> making no other changes – and submit to Data Tracker.
>
>
>
> Thanks.
>
>
>
> Joe
>
>
>
> *From: *OPSAWG  on behalf of Joe Clarke
> (jclarke) 
> *Date: *Tuesday, January 17, 2023 at 11:24
> *To: *opsawg@ietf.org 
> *Subject: *[OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP
> Flow Information Export (IPFIX) Information Element
>
> Happy new year, all.  One of the AIs that slipped through the cracks
> coming out of 115 was a call for adoption for
> draft-boucadair-opsawg-rfc7125-update.   One of the asks of Med at 115 was
> to look at what else might need to be done from an IE registry standpoint.
> He replied on-list to that a while ago:
>
>
>
> “Yes, I had a discussion with Benoît during the IETF meeting to see how
> to handle this. We agreed to proceed with at least two documents:
>
> · draft-boucadair-opsawg-rfc7125-update to update the TCP IPFIX
> RFC.
>
> · Edit a second draft to “clean” other entries in registry. This
> document is intended to include only simple fixes and which do not require
> updating existing RFCs. The candidate list of these 

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-12.txt

[tirumal reddy]

This revision addresses comments raised as part of SECDIR review.

-Tiru

On Mon, 30 Jan 2023 at 16:25,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
>   Filename: draft-ietf-opsawg-mud-tls-12.txt
>   Pages   : 34
>   Date: 2023-01-30
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-12
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-tls-12
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05

[tirumal reddy]

On Tue, 24 Jan 2023 at 20:27, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> > Agreed. My suggestion is to update the text as follows:
>
> > In TLS 1.3 with or without the use of ECH, middlebox cannot rely on
> SNI
> > inspection because a malware could lie about the SNI and middlebox
> without
> > acting as a TLS proxy does not have visibility into the server
> > certificate.
>
> Inserted, at:
>
> https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/36538767d4e2ed935bd52ed0f2d19f7bac879bba
>
> >> Is this still the right reference?  It seems that section 4 is still
> >> correct.
> >>
>
> > No, you will have to refer to DDR
> > (https://datatracker.ietf.org/doc/draft-ietf-add-ddr/) and DNR
> > (https://datatracker.ietf.org/doc/draft-ietf-add-dnr/).
> > The draft ietf-add-split-horizon-authority is specific to
> establishing
> > local DNS authority in Split-Horizon Environments. I don't think it
> is
> > relevant to this document.
>
> I have removed the second sentence/reference, and also the reference to
> peterson-doh-dhcp. I think that the existing DNR reference is enough.
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-iot-dns-considerations-07=draft-ietf-opsawg-mud-iot-dns-considerations-08=--html
>
> This is includes RFC9019 fix. Are there any other WGLC comments?
>

Updates look good to me.

Cheers,
-Tiru

>
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05

[tirumal reddy]

On Sun, 22 Jan 2023 at 22:47, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> > I support progressing the draft and I have the following
> comments/nits
> > which should be straightforward to address:
>
> > 1.
>
> > It has been suggested that one answer to this problem is to provide a
> > forced
> > intermediate for the TLS connections. This could in theory be done
> for TLS
> > 1.2 connections.
>
> I totally agree.  But, did you want more said here?
> I think that Ben's suggestion was to do everything via SOCKSv5, which would
> not have quite the same problems, but I think that is completely
> undeployable.
>

Agreed. My suggestion is to update the text as follows:

In TLS 1.3 with or without the use of ECH, middlebox cannot rely on SNI
inspection because a malware could lie about the SNI and middlebox without
acting as a TLS proxy does not have visibility into the server
certificate.


>
> > I would say SNI inspection is not useful in TLS 1.3 (with or without
> ECH).
>
> > 2.
> > XXX --- explain in detail how this can fail.
> > XXX --- explain N:1 vs 1:1 for virtual hosting.
>
> Nit> You may want to remove "XXX".
>
> I have expanded the contents.  I had feared this work would be impossible,
> but with sufficient coffee on a snowy Sunday morning, I think that I
> succeeded.
> Please see, and comment on:
>
> https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/6162d432cbc8395fa79b759f6ee9636a278ef800
>
> I've also appended the text to the end of this message, after my other
> actions.
>
> > 3.
> > The third section of this document details how current trends in DNS
> > presolution
> > such as public DNS servers, DNS over TLS (DoT), and DNS over HTTPS
> (DoH)
> > cause
> > problems for the strategies employed. Poor interactions with
> > content-distribution
> > networks is a frequent pathology that can result.
>
> Comment> You may also want to refer to DoQ.
>
> Done.
>
> > 4.
> > A third problem involves the use of HTTPS. IP address literals do not
> > provide enough
> > context for TLS ServerNameIndicator to be useful [RFC6066]. This
> limits the
> > firmware repository to be a single tenant on that IP address, and
> for IPv4
> > (at least),
> > this is no longer a sustainable use of IP addresses.
>
> tiru> You may want to look into
> tiru> https://www.rfc-editor.org/rfc/rfc8738.html, it will address
> the limitation
> tiru> with IP address as an identifier in certificates.
>
> I don't think that automating IP address inclusion in certificates is
> useful or the point here.
> During a big distribution even, a supplier might massively increase the
> number of servers that serve particular content.  (Netflix among others
> does this)
> If HTTPS is to be used, the servers need certificates, and if the servers
> are
> referenced by IP address, then they can't do virtual hosting of any time.
>
> This is contrasted to systems like Amazon S3, where a single *name* could
> be
> distributed among hundreds of servers, and at the same time, those servers
> (IP address end-points) could also be hosting content for hundreds of
> names.
>

Got it, Thanks.


>
> > 5. Section 6.5> I suggest replacing the references by the drafts
> adopted by
> > ADD WG (DNR and DDR)..
>
> okay.
>
>Secure discovery of network provided DoH/DoT resolver is possible using
>the mechanisms discussed in {{?I-D.ietf-add-split-horizon-authority}}
>section-4.
>
> Is this still the right reference?  It seems that section 4 is still
> correct.
>

No, you will have to refer to DDR
(https://datatracker.ietf.org/doc/draft-ietf-add-ddr/) and DNR
(https://datatracker.ietf.org/doc/draft-ietf-add-dnr/).
The draft ietf-add-split-horizon-authority is specific to establishing
local DNS authority in Split-Horizon Environments. I don't think it is
relevant to this document.

-Tiru


>
> ===
> the "it won't work" text:
>
> The most naive method is to try to map IP addresses to names using the
> in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings.
>
> ## Failing strategy
>
> Attempts to map IP address to names in real time fails for a number of
> reasons:
>
> 1. it can not be done fast enough,
>
> 2. it reveals usage patterns of the devices,
>
> 3. the mapping are often incomplete,
>
> 4. even if the mapping is present, due to virtual hosting, it may not map
> back to the name used in the ACL.
>
> This is not a su

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05

[tirumal reddy]

I support progressing the draft and I have the following comments/nits
which should be straightforward to address:

1.

It has been suggested that one answer to this problem is to provide a
forced
intermediate for the TLS connections. This could in theory be done for TLS
1.2 connections.
The MUD policy enforcement point could observe the Server Name Identifier
(SNI) [RFC6066].
Some Enterprises do this already. But, as this involves active termination
of the TCP
connection (a forced circuit proxy) in order to see enough of the traffic,
it
requires significant effort. But, TLS 1.3 provides options to encrypt the
SNI as the
ESNI, which renders the practice useless in the end.

Comment> In TLS 1.3, the client can lie about SNI and a firewall passively
inspecting the handshake cannot identify it without looking into the server
certificate (which is not possible).

I would say SNI inspection is not useful in TLS 1.3 (with or without ECH).

2.
XXX --- explain in detail how this can fail.
XXX --- explain N:1 vs 1:1 for virtual hosting.

Nit> You may want to remove "XXX".

3.
The third section of this document details how current trends in DNS
presolution
such as public DNS servers, DNS over TLS (DoT), and DNS over HTTPS (DoH)
cause
problems for the strategies employed. Poor interactions with
content-distribution
networks is a frequent pathology that can result.

Comment> You may also want to refer to DoQ.

4.
A third problem involves the use of HTTPS. IP address literals do not
provide enough
context for TLS ServerNameIndicator to be useful [RFC6066]. This limits the
firmware repository to be a single tenant on that IP address, and for IPv4
(at least),
this is no longer a sustainable use of IP addresses.

Comment> You may want to look into
https://www.rfc-editor.org/rfc/rfc8738.html, it will address the limitation
with IP address as an identifier in certificates.

5. Section 6.5> I suggest replacing the references by the drafts adopted by
ADD WG (DNR and DDR)..

Cheers,
-Tiru


On Fri, 9 Dec 2022 at 21:53, Henk Birkholz 
wrote:

> Dear OPSAWG members,
>
> this email starts a four week period for a Working Group Last Call of
>
> >
> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-05.html
>
> ending on Friday, January 6th 2023.
>
> Several reviews of this document were submitted. The most recent one
> from the Security Directorate was addressed. The authors believe the
> Internet-Draft is ready for a WGLC and the chairs are in support of a
> WGLC. The draft has been discussed visibly on the list and at previous
> IETF meetings.
>
> Please reply with your active support (+1 required) or objections and
> your assessment of whether or not it is ready to proceed to publication
> before January 6th 2023.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [secdir] Secdir last call review of draft-ietf-opsawg-mud-tls-10

[tirumal reddy]

Hi Ben,

I re-looked into the discussion in the TLS WG mailing list and we have
addressed all the comments raised by the WG members.

The issues raised by the TLS WG and addressed in the draft are:

(a) We added Section 6 to explain the rules to processing the MUD (D)TLS
rules to handle ossification and updated Section 10 to enable faster update
to the YANG module.
(b) Updates to the draft that the YANG module must not include GREASE
values (see Section 5).
(c) Privacy issues related to not revealing the MUD URL to an attacker is
discussed in Section 9.

Please let us know if you see any other pending issues.

Cheers,
-Tiru

On Fri, 6 Jan 2023 at 21:43, Ben Schwartz  wrote:

> Since this happened to cross my inbox, I want to reiterate that, in my
> view, this document has not been properly reviewed by the TLS WG.  As the
> shepherd's writeup notes, previous reviews in the TLS group raised some
> significant concerns about whether this draft's approach is advisable.
>
> I would encourage the responsible AD(s) to make sure that this document
> has strong consensus support from the TLS WG before proceeding.
>
> On Fri, Nov 18, 2022 at 12:29 PM Linda Dunbar via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Linda Dunbar
>> Review result: Has Nits
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing
>> effort to review all IETF documents being processed by the IESG.  These
>> comments were written primarily for the benefit of the security area
>> directors.
>> Document editors and WG chairs should treat these comments just like any
>> other
>> last-call comments.
>>
>> This document extends the Manufacturer Usage Description specification to
>> incorporate the (D)TLS profile parameters for a network security service
>> to
>> identify unexpected (D)TLS usage. The document has very good description
>> of
>> common malware behavior that is informative.
>>
>> Questions
>> - Are the profile on the remote IoT device or on the network device? If
>> the
>> profile is on remote IoT devices, are those attributes in the profiles
>> attached
>> as metadata when requesting TLS connections? Are those attributes
>> encrypted? -
>> If the Malware on IoT doesn't participate in TLS, can those MUD be used to
>> detect the Malware on the remote IoT devices?
>>
>> - Page 6, first paragraph says:
>>  "malware developers will have to develop malicious agents per IoT device
>> type,
>>  manufacturer and model, infect the device with the tailored malware
>> agent and
>>  will have keep up with updates to the device's (D)TLS profile parameters
>> over
>>  time."
>>
>> Does it mean that if all the IoT devices deployed in the network register
>> their
>> DeviceType/ManufacturerName/Model with the network services, then the
>> network
>> services can validate the TLS requests from the IoT?
>>
>> -  Section 3 last paragraph says that "compromised IoT devices are
>> typically
>> used for launching DDoS attacks". Can today's TLS re-negotiation validate
>> the
>> TLS requests by evaluating if the server certificates are signed by the
>> same
>> certifying authorities trusted by the IoT device"?
>>
>> Thank you very much,
>>
>> Linda Dunbar
>>
>>
>> ___
>> secdir mailing list
>> sec...@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
>>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-mud-tls-10

[tirumal reddy]

Hi Linda,

Thanks for the review. Please see inline

On Fri, 18 Nov 2022 at 22:58, Linda Dunbar via Datatracker 
wrote:

> Reviewer: Linda Dunbar
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.
> Document editors and WG chairs should treat these comments just like any
> other
> last-call comments.
>
> This document extends the Manufacturer Usage Description specification to
> incorporate the (D)TLS profile parameters for a network security service to
> identify unexpected (D)TLS usage. The document has very good description of
> common malware behavior that is informative.
>
> Questions
> - Are the profile on the remote IoT device or on the network device?


The TLS profile on the IoT device is signalled to the network device using
MUD (see https://datatracker.ietf.org/doc/rfc8520/) .


> If the
> profile is on remote IoT devices, are those attributes in the profiles
> attached
> as metadata when requesting TLS connections?


No.


> Are those attributes encrypted? -
>

Yes, the TLS profile is learned from a MUD file, it will be retrieved
using the "https" scheme.


> If the Malware on IoT doesn't participate in TLS, can those MUD be used to
> detect the Malware on the remote IoT devices?
>

If the IoT device is supposed to use TLS as per the MUD file, but the
firewall sees some other type of traffic from the IoT device it cannot
identify, it can assume malicious traffic and can take
appropriate action.


>
> - Page 6, first paragraph says:
>  "malware developers will have to develop malicious agents per IoT device
> type,
>  manufacturer and model, infect the device with the tailored malware agent
> and
>  will have keep up with updates to the device's (D)TLS profile parameters
> over
>  time."
>
> Does it mean that if all the IoT devices deployed in the network register
> their
> DeviceType/ManufacturerName/Model with the network services, then the
> network
> services can validate the TLS requests from the IoT?
>

Yes, it is extending MUD which defines layers 3 and 4 ACLs for IoT devices.


>
> -  Section 3 last paragraph says that "compromised IoT devices are
> typically
> used for launching DDoS attacks". Can today's TLS re-negotiation validate
> the
> TLS requests by evaluating if the server certificates are signed by the
> same
> certifying authorities trusted by the IoT device"?
>

In this attack, the client completes the TLS handshake but then immediately
requests a renegotiation of the encryption method. As soon as the
renegotiation completes, it requests another renegotiation, and so on to
cause
an attack on the server.

Cheers,
-Tiru

>
> Thank you very much,
>
> Linda Dunbar
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-11.txt

[tirumal reddy]

This revision
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-11 addresses
YANGDOCTOR review comments from *Xufeng.*

*-Tiru*

On Mon, 12 Dec 2022 at 20:22,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
>   Filename: draft-ietf-opsawg-mud-tls-11.txt
>   Pages   : 37
>   Date: 2022-12-12
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-11
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-tls-11
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-mud-tls-10

[tirumal reddy]

Thanks Xufeng for the detailed review. Please see inline

On Sat, 10 Dec 2022 at 05:56, Xufeng Liu via Datatracker 
wrote:

> Reviewer: Xufeng Liu
> Review result: Ready with Issues
>
> This is a review of the YANG module in draft-ietf-opsawg-mud-tls-10.
>
> Sec 5.1. and 5.2
>
> 1) The container “client-profile” is duplicated twice. Is there any reason
> for
> the duplication?
>

It was added by mistake, I will remove the duplication.


>
> 2) As a convention, in IETF YANG modules, the node name of a list is in the
> singular form. Above the list there can be a container with a name in the
> plural form. For example, in RFC8519, there are a container “acls” and a
> list
> “acl”. Using such a convention, the container “client-profile” would be
> better
> named as “client-profiles”, and the list “tls-dtls-profiles” would be
> better
> named as “tls-dtls-profile”. The same is applicable to other list names,
> such
> as “tls-dtls-profiles”, “cipher-suites”, “extension-types”,  and
> “signature-algorithms-cert”.
>

Thanks, I wil fix the above names accordingly.


>
> 3) The leaf-list “acceptlist-ta-certs” can be better named as
> “accept-list-ta-certs” per RFC8407.
>

Sure.


>
> 4) Default values should be specified or explained for optional leaves like
> “spki-hash-algorithm”.
>

Okay.


>
> 5) The leaf “profile-name” is suggested to be renamed to “name”. As
> described
> in Sec 4.3.1. of RFC8407, child nodes within a container or list SHOULD NOT
> replicate the parent identifier.
>

Done.


>
> Sec. 5.3. IANA (D)TLS profile YANG Module
>
> 1) This section indicates that there are no IANA-maintained values for
> spki-pin-set, and certificate-authority parameters. If so, what are the
> reasons
> to include these two types in this IANA YANG module? What do we expect
> IANA to
> maintain and update?
>

I see your point, I will remove these types from the IANA YANG module.


>
> Sec. 5.4. MUD (D)TLS Profile Extension
>
> 1) The file name of the YANG module is wrong. It seems to be a typo.
>

Yes, fixed.


>
> 2) The statement “import ietf-mud” needs to have a “reference”
> sub-statement.
>

Added.


>
> 3) The leaf “is-tls-dtls-profile-supported” should have a default value or
> a
> description of the default behavior.
>

Okay.


>
> Sec 7.
>
> 1) In the example, the leaf “profile-name” is needed as it is the key of
> the
> list.
>

Yes.


>
> Sec 10.1.
>
> 1) For iana module, iana-tls-profile, instead of “Registrant Contact:
> IESG”, we
> should have Registrant Contact: IANA
>

Fixed.


>
> [Nit]:
>
> 1) The following code contains a line longer than 69 characters:
> leaf hash {
>   type ianatp:hash-algorithm;
>   description
> "Hash algorithm used with HKDF as defined in RFC5869.";
> }
>

Done.

Cheers,
-Tiru


>
> Thanks,
> - Xufeng
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

On Mon, 17 Oct 2022 at 16:28, tom petch  wrote:

> inline  one minor editorial comment plus a technical one which I do
> not know the answer to.
>
> From: tirumal reddy 
> Sent: 14 October 2022 14:01
>
> On Fri, 14 Oct 2022 at 16:46, tom petch  ie...@btconnect.com>> wrote:
> From: tirumal reddy mailto:kond...@gmail.com>>
> Sent: 14 October 2022 09:22
>
> On Thu, 13 Oct 2022 at 16:55, tom petch  ie...@btconnect.com><mailto:ie...@btconnect.com<mailto:ie...@btconnect.com>>>
> wrote:
> From: tirumal reddy mailto:kond...@gmail.com> kond...@gmail.com<mailto:kond...@gmail.com>>>
> Sent: 13 October 2022 07:57
>
> Thanks Tom for the review. Yes, we will fix the references identified by
> Tom.
>
> 
> -09 looks better.
>
> I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a
> rationale for that.  I prefer the former but that mix of characters may
> confuse others.
>
> Good point, fixed in my copy
> https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt
> .
>
>
> I see a number of editorial issues - I do not know if you want to look at
> those now or leave them to Last Call.
>
> Please feel free to raise the editorial issues, we will fix them.
>
>
> One slightly technical one is that it is very rare to start a YANG prefix
> with ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT
> IMHO.  Thus acl has a prefix of acl so I would see the augment as acl-tls
> and not ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment
> is perhaps  better as ietf-mud-tls.
>
> We followed the format similar to ietf-access-control-list (YANG data
> model of network ACL) and ietf-mud to be consistent.
>
> 
> Um, that is not what I see.  It is the prefix I have in mind where RFC8519
> specifies a prefix of acl and that is what you use in the import.  An
> extension to that module could then have a prefix of acl-xxx or some such
> where you have specified ietf-acl-tls.  It is that 'ietf' that I see as
> unusual.
>
> Got it, changed the prefix to "acl-tls".
>
>
> Editorially, not all of which you may want to fix at this time
>
> 'The YANG module specified in Section 5...'
> suggest adding the subsection since there is more than one
>
> 'specific terms are used'
> suggest using the terms here e.g. TLS and DTLS are used
>
> s.4
> incapable to decipher
> perhaps 'unable to decipher' or 'incapable of deciphering'
>
> s.5.1
> Add an Infornative Reference to RFC8340 for the meaning of tree diagrams
>
> s.5.2
> /Simplified BSD/Revised BSD/
>
> revision date is out of date
>
> SPKI probably needs expanding both in the body and in the YANG modules
>
> The description of certificate-authorities looks like it is too long for
> an RFC
>
> s.5.3
> BSD license again
>
> revision date again
>
> s.5.4
> ditto
>
> author e-mail address is not the same as elsewhere
>
> YANG import MUST have a reference clause which MUST be a Normative
> reference
>
> Thanks, I fixed all the above editorial issues.
>
> 
> Almost.  I am still seeing a YANG import in s.5.4 which has no reference
> clause.
>

Thanks, fixed in git repo.


>
> Also, there is a technical YANG issue to which I do not know the answer
> and have posted that to the netmod list.  AFAICT there has been no YANG
> Doctor review and it is an issue that at least some YANG Doctors would
> comment on
>

We will publish the revised version after the review from YANG Doctor and
the response to your question in netmod list.

Cheers,
-Tiru


>
> Tom Petch
>
> does profile-supported have a default ?
>
> No.
>
>
> s.8
> There is a template for YANG security as referenced by RFC8407 which I
> note is not used here
>
> Thanks, added note that it is not applicable to draft as it is not meant
> to be accessed via NETCONF/RESTCONF..
>
>
> s.9
> I note that this is TLS and not (D)TLS. Is that intended?  s.4 uses the
> latter
>
> Fixed, it is supposed to be (D)TLS.
>
>
> s.10
> When specifying Expert Review, guidance is often given as to what the
> experts should look for and where.
>
> Yes, I added details for Expert Review..
>
> Cheers,
> -Tiru
>
>
> Tom Petch
>
>
>
>
>
> Cheers,
> -Tiru
>
>
>
> Tom Petch
>
> Cheers,
> -Tiru
>
> On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de<mailto:henk.birkh...@sit.fraunhofer.de
> ><mailto:henk.birkh...@sit.fraunhofer.de henk.birkh...@sit.fraunhofer.de>><mailto:henk.birkh...@sit.fraunhofer.de
> <mailto:henk.birkh...@sit.fraunhofer.de>

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

On Fri, 14 Oct 2022 at 16:46, tom petch  wrote:

> From: tirumal reddy 
> Sent: 14 October 2022 09:22
>
> On Thu, 13 Oct 2022 at 16:55, tom petch  ie...@btconnect.com>> wrote:
> From: tirumal reddy mailto:kond...@gmail.com>>
> Sent: 13 October 2022 07:57
>
> Thanks Tom for the review. Yes, we will fix the references identified by
> Tom.
>
> 
> -09 looks better.
>
> I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a
> rationale for that.  I prefer the former but that mix of characters may
> confuse others.
>
> Good point, fixed in my copy
> https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt
> .
>
>
> I see a number of editorial issues - I do not know if you want to look at
> those now or leave them to Last Call.
>
> Please feel free to raise the editorial issues, we will fix them.
>
>
> One slightly technical one is that it is very rare to start a YANG prefix
> with ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT
> IMHO.  Thus acl has a prefix of acl so I would see the augment as acl-tls
> and not ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment
> is perhaps  better as ietf-mud-tls.
>
> We followed the format similar to ietf-access-control-list (YANG data
> model of network ACL) and ietf-mud to be consistent.
>
> 
> Um, that is not what I see.  It is the prefix I have in mind where RFC8519
> specifies a prefix of acl and that is what you use in the import.  An
> extension to that module could then have a prefix of acl-xxx or some such
> where you have specified ietf-acl-tls.  It is that 'ietf' that I see as
> unusual.
>

Got it, changed the prefix to "acl-tls".


>
> Editorially, not all of which you may want to fix at this time
>
> 'The YANG module specified in Section 5...'
> suggest adding the subsection since there is more than one
>
> 'specific terms are used'
> suggest using the terms here e.g. TLS and DTLS are used
>
> s.4
> incapable to decipher
> perhaps 'unable to decipher' or 'incapable of deciphering'
>
> s.5.1
> Add an Infornative Reference to RFC8340 for the meaning of tree diagrams
>
> s.5.2
> /Simplified BSD/Revised BSD/
>
> revision date is out of date
>
> SPKI probably needs expanding both in the body and in the YANG modules
>
> The description of certificate-authorities looks like it is too long for
> an RFC
>
> s.5.3
> BSD license again
>
> revision date again
>
> s.5.4
> ditto
>
> author e-mail address is not the same as elsewhere
>
> YANG import MUST have a reference clause which MUST be a Normative
> reference
>

Thanks, I fixed all the above editorial issues.


>
> does profile-supported have a default ?
>

No.


>
> s.8
> There is a template for YANG security as referenced by RFC8407 which I
> note is not used here
>

Thanks, added note that it is not applicable to draft as it is not meant to
be accessed via NETCONF/RESTCONF..


>
> s.9
> I note that this is TLS and not (D)TLS. Is that intended?  s.4 uses the
> latter
>

Fixed, it is supposed to be (D)TLS.


>
> s.10
> When specifying Expert Review, guidance is often given as to what the
> experts should look for and where.
>

Yes, I added details for Expert Review..

Cheers,
-Tiru


>
> Tom Petch
>
>
>
>
>
> Cheers,
> -Tiru
>
>
>
> Tom Petch
>
> Cheers,
> -Tiru
>
> On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de<mailto:henk.birkh...@sit.fraunhofer.de
> ><mailto:henk.birkh...@sit.fraunhofer.de henk.birkh...@sit.fraunhofer.de>>> wrote:
> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG mailto:opsawg-boun...@ietf.org
> ><mailto:opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>>> on
> behalf of Henk Birkholz  henk.birkh...@sit.fraunhofer.de><mailto:henk.birkh...@sit.fraunhofer.de
> <mailto:henk.birkh...@sit.fraunhofer.de>>>
> > Sent: 06 October 2022 13:26
> >
> > Dear authors and contributors,
> >
> > thank you for your hard work. As it seems that all existing issues have
> > been resolve, we'll move the I-D to write-up in the datatracker.
> >
> > Also, thanks Thomas Fossati for stepping up as shepherd!
> >
> > 
> > My main comment on this remains th

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

On Thu, 13 Oct 2022 at 16:55, tom petch  wrote:

> From: tirumal reddy 
> Sent: 13 October 2022 07:57
>
> Thanks Tom for the review. Yes, we will fix the references identified by
> Tom.
>
> 
> -09 looks better.
>
> I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a
> rationale for that.  I prefer the former but that mix of characters may
> confuse others.
>

Good point, fixed in my copy
https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt
.


>
> I see a number of editorial issues - I do not know if you want to look at
> those now or leave them to Last Call.
>

Please feel free to raise the editorial issues, we will fix them.


>
> One slightly technical one is that it is very rare to start a YANG prefix
> with ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT
> IMHO.  Thus acl has a prefix of acl so I would see the augment as acl-tls
> and not ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment
> is perhaps  better as ietf-mud-tls.


We followed the format similar to ietf-access-control-list (YANG data model
of network ACL) and ietf-mud to be consistent.

Cheers,
-Tiru


>
>
> Tom Petch
>
> Cheers,
> -Tiru
>
> On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de<mailto:henk.birkh...@sit.fraunhofer.de>>
> wrote:
> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG mailto:opsawg-boun...@ietf.org>>
> on behalf of Henk Birkholz  henk.birkh...@sit.fraunhofer.de>>
> > Sent: 06 October 2022 13:26
> >
> > Dear authors and contributors,
> >
> > thank you for your hard work. As it seems that all existing issues have
> > been resolve, we'll move the I-D to write-up in the datatracker.
> >
> > Also, thanks Thomas Fossati for stepping up as shepherd!
> >
> > 
> > My main comment on this remains the mix of two different YANG modules
> with different life cycles; I expect that l will comment again on the Last
> Call list to give this issue more exposure.
> >
> > Of lesser import, I cannot make sense of the references.
> > I see [RFC5246] which normally means that a reference has been created.
> Not here, so there would seem to have been some chicanery involved, that
> this I-D has not been produced by the usual IETF tools.
> >
> > I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D
> References.
> >
> > dtls13 is now an RFC.
> >
> > What is the difference between
> > draft-ietf-tls-dtls13:
> > and
> >  "RFC : Datagram Transport Layer Security 1.3";
> >   ?
> > How do I find
> >  "RFC : Common YANG Data Types for Cryptography";
> >   or
> > "RFC : Common YANG Data Types for Hash algorithms"; ?
> >
> > Does tls-1-2 mean the same as tls-1.2?  And is this the same as that
> which the Netconf WG refers to as tls12?
> >
> > Tom Petch
> >
> >
> > For the OPSAWG co-chairs,
> >
> > Henk
> >
> >
> > On 29.09.22 10:27, Henk Birkholz wrote:
> >> Dear OPSAWG members,
> >>
> >> this email concludes the first WGLC call for
> >> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html.
> >>
> >> A few comments where raised. Authors/editors, please go ahead and
> >> address these as discussed on the list.
> >>
> >>
> >> For the OPSAWG co-chairs,
> >>
> >> Henk
> >>
> >> On 14.09.22 16:07, Henk Birkholz wrote:
> >>> Dear OPSAWG members,
> >>>
> >>> this email starts a two week period for a Working Group Last Call of
> >>>
> >>>> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html
> >>>
> >>> ending on Thursday, September 28th.
> >>>
> >>> The authors believe the Internet-Draft is ready for a WGLC and the
> >>> chairs agree. The draft has been discussed visibly at IETF 114 and
> >>> review feedback has been incorporated in -07.
> >>>
> >>> Please send your comments to the list and your assessment of whether
> >>> or not it is ready to proceed to publication before September 28th.
> >>>
> >>>
> >>> For the OPSAWG co-chairs,
> >>>
> >>> Henk
> >>
> >> ___
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
> > https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

Thanks Tom for the review. Yes, we will fix the references identified by
Tom.

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 18:37, Henk Birkholz 
wrote:

> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG  on behalf of Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de>
> > Sent: 06 October 2022 13:26
> >
> > Dear authors and contributors,
> >
> > thank you for your hard work. As it seems that all existing issues have
> > been resolve, we'll move the I-D to write-up in the datatracker.
> >
> > Also, thanks Thomas Fossati for stepping up as shepherd!
> >
> > 
> > My main comment on this remains the mix of two different YANG modules
> with different life cycles; I expect that l will comment again on the Last
> Call list to give this issue more exposure.
> >
> > Of lesser import, I cannot make sense of the references.
> > I see [RFC5246] which normally means that a reference has been created.
> Not here, so there would seem to have been some chicanery involved, that
> this I-D has not been produced by the usual IETF tools.
> >
> > I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D
> References.
> >
> > dtls13 is now an RFC.
> >
> > What is the difference between
> > draft-ietf-tls-dtls13:
> > and
> >  "RFC : Datagram Transport Layer Security 1.3";
> >   ?
> > How do I find
> >  "RFC : Common YANG Data Types for Cryptography";
> >   or
> > "RFC : Common YANG Data Types for Hash algorithms"; ?
> >
> > Does tls-1-2 mean the same as tls-1.2?  And is this the same as that
> which the Netconf WG refers to as tls12?
> >
> > Tom Petch
> >
> >
> > For the OPSAWG co-chairs,
> >
> > Henk
> >
> >
> > On 29.09.22 10:27, Henk Birkholz wrote:
> >> Dear OPSAWG members,
> >>
> >> this email concludes the first WGLC call for
> >> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html.
> >>
> >> A few comments where raised. Authors/editors, please go ahead and
> >> address these as discussed on the list.
> >>
> >>
> >> For the OPSAWG co-chairs,
> >>
> >> Henk
> >>
> >> On 14.09.22 16:07, Henk Birkholz wrote:
> >>> Dear OPSAWG members,
> >>>
> >>> this email starts a two week period for a Working Group Last Call of
> >>>
>  https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html
> >>>
> >>> ending on Thursday, September 28th.
> >>>
> >>> The authors believe the Internet-Draft is ready for a WGLC and the
> >>> chairs agree. The draft has been discussed visibly at IETF 114 and
> >>> review feedback has been incorporated in -07.
> >>>
> >>> Please send your comments to the list and your assessment of whether
> >>> or not it is ready to proceed to publication before September 28th.
> >>>
> >>>
> >>> For the OPSAWG co-chairs,
> >>>
> >>> Henk
> >>
> >> ___
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-add-encrypted-dns

[tirumal reddy]

No, I'm not aware of any IPR that applies to this draft.

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 22:16, Joe Clarke (jclarke) 
wrote:

> Authors and contributors, please respond on-list as to whether or not you
> are aware of any IPR that pertains to this work.
>
>
>
> Please state either:
>
>
>
> "No, I'm not aware of any IPR that applies to this draft"
>
> or
>
> "Yes, I'm aware of IPR that applies to this draft"
>
>
>
> If you are aware of IPR, indicate whether or not this has been disclosed
> per IETF IPR rules (see RFCs 3669, 5378, and 8179).
>
>
>
> Joe
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-08.txt

[tirumal reddy]

This revision adds a note to the implementers or users of this draft to
refer to the IANA-maintained "iana-tls-profile" YANG module.

Cheers,
-Tiru

On Mon, 3 Oct 2022 at 11:45,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
>   Filename: draft-ietf-opsawg-mud-tls-08.txt
>   Pages   : 34
>   Date: 2022-10-02
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-08
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  IPR Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

No, I'm not aware of any IPR that applies to this draft.

-Tiru

On Thu, 29 Sept 2022 at 14:00, Henk Birkholz <
henk.birkh...@sit.fraunhofer.de> wrote:

> Dear authors and contributors,
>
> as a reminder: please respond on-list as to whether or not you are aware
> of any IPR that pertains to draft-ietf-opsawg-mud-tls-07.
>
> State either:
>
> "No, I'm not aware of any IPR that applies to this draft."
>
> or
>
> "Yes, I'm aware of IPR that applies to this draft."
>
> If you are aware of IPR, please also indicate whether or not this has
> been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179).
>
>
> For the OPAWG co-chairs,
>
> Henk
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

Thanks Tom and Med for the feedback. We will add a note that users should
visit the IANA URL with the Yang module. The new guidelines for the
IANA-maintained modules need to be discussed in the netmod WG (updating
RFC8216), till then, we will have to follow the existing guidelines as
other specifications.

Cheers,
-Tiru

On Fri, 16 Sept 2022 at 16:15, tom petch  wrote:

> From: mohamed.boucad...@orange.com 
> Sent: 15 September 2022 12:35
>
> Hi Tom,
>
> This is a fair comment.
>
> There is currently no recommendation on whether the initial full
> IANA-maintained modules should (not) be included or whether "an
> IANA-maintained module should
> always be published on its own". Publishing the module in a separate
> document has the same issues as those that are called out in the last two
> sentences of the excerpt below from
> https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries-04;
> I don't think it is worth to be considered by the authors here:
>
> 
> Well, I have a recommendation.  I think that the initial version of an
> IANA-maintained module should appear in an RFC on its own.  That RFC can
> then be classified as Historic after a brief pause.
>
> The initial version should be there so that we can see how we got to
> whereever we later get to.  Authors can, and do, add a note to the effect
> that users should visit the IANA website, and give a URL,  Such a note
> should always be present IMO.
>
> Tom Petch
>
>Designers of IANA-maintained modules MAY supply the full initial
>version of the module in a specification document that registers the
>module or only a script to be used (including by IANA) for generating
>the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108]).
>When a script is used, the Internet-Draft that defines an IANA-
>maintained module SHOULD include an appendix with the initial full
>version of the module.  Including such an appendix in pre-RFC
>versions is meant to assess the correctness of the outcome of the
>supplied script.  The authors MUST include a note to the RFC Editor
>requesting that the appendix be removed before publication as RFC.
>Initial versions of IANA-maintained modules that are published in
>RFCs may be misused despite the appropriate language to refer to the
>IANA registry to retrieve the up-to-date module.  This is problematic
>for interoperability, e.g., when values are deprecated or are
>associated with a new meaning.
>
> As an alternative to the script mentioned above, I wonder whether the
> authors can simply include a note to the RFC Editor asking to remove the
> module from the RFC and replace it with a link to the IANA page with the
> module.
>
> That's said, I'm having troubles with the content of the IANA-maintained
> module itself because it does not reflect the content of the authoritative
> registries it refers to. Also, I'm not sure the current IANA instructions
> are unambiguous so that IANA can maintain the module.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : OPSAWG  De la part de tom petch
> > Envoyé : jeudi 15 septembre 2022 11:25
> > À : Henk Birkholz ; opsawg
> > 
> > Objet : Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-
> > tls-07
> >
> > From: OPSAWG  on behalf of Henk Birkholz
> > 
> > Sent: 14 September 2022 15:07
> >
> > Dear OPSAWG members,
> >
> > this email starts a two week period for a Working Group Last Call
> > of
> >
> > > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-
> > 07.html
> >
> > ending on Thursday, September 28th.
> >
> > The authors believe the Internet-Draft is ready for a WGLC and the
> > chairs agree. The draft has been discussed visibly at IETF 114 and
> > review feedback has been incorporated in -07.
> >
> > Please send your comments to the list and your assessment of
> > whether or not it is ready to proceed to publication before
> > September 28th.
> >
> > 
> > Not Ready.
> >
> > This I-D contains a YANG module for IANA to maintain along with
> > YANG modules and other data which are not.  I think that this
> > approach is always wrong.  The two sets of material have different
> > life cycles.  The IANA-maintained module is effectively obsolete
> > as soon as the RFC is published since the contents are then
> > maintained by IANA; anyone seeing the module in the RFC will be
> > looking at obsolete - sooner or later - material.  Users should
> > always be looking at the IANA website.  There is no way to tell
> > users this in the published status of an RFC.
> >
> > The remaining material in the I-D is likely to be updated over
> > time and then the authors have a choice of two bad approaches.
> > They can cut out the IANA-maintained module in which case the new
> > document sort of obsoletes the old one but not quite and a lot
> > more editing is needed; or they can republish the IANA-maintained
> > module which by then will have been obsolete for some time and
> > almost certainly 

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-07.txt

[tirumal reddy]

This version addresses comments received during the presentation at
IETF-114. It looks ready for WGLC.

Cheers,
-Tiru

On Fri, 26 Aug 2022 at 14:56,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
>   Filename: draft-ietf-opsawg-mud-tls-07.txt
>   Pages   : 34
>   Date: 2022-08-26
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-07
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-06.txt

[tirumal reddy]

In this revised draft
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-06, (D)TLS
1.3 section is updated to discuss ECH. Further comments and suggestions are
welcome.

Cheers,
-Tiru

On Sun, 6 Mar 2022 at 12:48,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
> Filename: draft-ietf-opsawg-mud-tls-06.txt
> Pages   : 34
> Date: 2022-03-05
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-06
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] revisions in draft-ietf-opsawg-mud-iot-dns-considerations-01

[tirumal reddy]

Hi Michael,

Please see inline

On Mon, 22 Feb 2021 at 04:39, Michael Richardson 
wrote:

>
> Reorganized your comments to bring the discussion to the top.
>
> > 5) Wildcard certificates are also commonly available which allowed
> for
> > an infinite number of possible names.
>
> Comment> https://tools.ietf.org/html/rfc6125#section-6.4.3 does not
> Comment> recommend the use of wildcard certificates.
>
> okay, but they are widely used in Enterprises, and the point here is that
> having a unique name for each product model's download server should not
> be a
> burden.
> So, while I'm not trying to disagree with RFC6125, I don't think it
> materially
> matters here.
>
> > 6) Where the solution is more complex is when the MUD controller is
> > located elsewhere in an Enteprise, or remotely in a cloud such as
> when
> > a Software Defines Network (SDN) is used to manage the ACLs.  The DNS
> > servers for a particular device may not be known to the MUD
> controller,
> > nor the MUD controller be even permitted to make recusive queries
> that
> > server if it is known.  In this case, additional installation
> specific
> > mechanisms are probably needed to get the right view of DNS.
>
> Comment> The MUD controller can program the Enterprise DNS resolver to
> Comment> enforce the DNS filtering rules. DNS resolvers can enforce
> Comment> device  specific filtering.
>
> I think that your comment misses the point.
> It isn't about DNS filtering, it's about the MUD controller getting the
> same
> view of DNS as the device.
>

I don't think it is possible for the MUD manager to get the same responses
to DNS queries as the IoT device even if both of them use the same DNS
recursive server (e.g., successive DNS queries may never resolve to the
same IP address).


>
>
> tirumal reddy  wrote:
> > Use of DoT to a local DNS recursive resolver is a preferred choice,
> > assuming that the trust anchor for the local DNS server can be
> > obtained, such as via [I-D.reddy-dprive-bootstrap-dns-server].
>
> Comment> I would replace DoT with "Encrypted DNS connection"
>
> Done.
>
> > 2) The use of DoT and DoH eliminates the minimizes threat from
> passive
> > eavesdropped, but still exposes the list to the operator of the DoT
> or
> > DoH server.
>
> Comment> The threat is further minimized by the use of oblivous DNS
> Comment>
> https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-03
> Comment> (see https://blog.cloudflare.com/oblivious-dns/).
>
> Done.
>
> > 3) IoT devices that reach out to the manufacturer at regular
> intervals
> > to check for firmware updates are informing passive eavesdroppers of
> > the existence of a specific manufacturer's device being present at
> the
> > origin location.
>
> Comment> Identifying the IoT device type empowers the attacker to
> launch
> Comment> targeted attacks to the IoT device (e.g., Attacker can
> advantage
> Comment> of the device vulnerability).
>
> Done.
>
> However, I don't want to overstate this.
> An attacker internal to the network, for which internal ACLs do not work
> (because of lack of L2 hairpinning) may be able to fingerprint the device
> independantly, and attack it directly.
> An attacker external to the network, should not, given appropriate incoming
> MUD ACLs, be able to even connect to the device.
>
> So, I'm really more worried about privacy issues here.
>

Okay.


>
> > 4) IoT Devices should prefer doing DNS to the network provided DNS
> > servers.  Whether this is restricted to Classic DNS (Do53) or also
> > includes using DoT/DoH is a local decision, but a locally provided
> DoT
> > server SHOULD be used, as recommended by
> > [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp].
>
> Comment> ADD WG is currently only focusing on insecure discovery
> Comment> mechanisms like DHCP/RA
> Comment> (https://tools.ietf.org/html/draft-btw-add-home-10) and DNS
> Comment> based discovery mechanisms
> Comment> (https://tools.ietf.org/html/draft-pauly-add-deer-00). Secure
> Comment> discovery of network provided DoH/DoT resolver is possible
> using
> Comment> the mechanisms discussed in
> Comment>
> https://tools.ietf.org/html/draft-reddy-add-enterprise-00#section-4.
>
> Done.  Only, draft-reddy-add-enterprise has expired ...
>

ADD WG has adopted DDR and DNR drafts (both are insecure discovery
mechanisms). I am hoping the WG will discuss secure discovery mechanisms
like BRSKI and SZTP for IoT devices.

-Tiru


>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-04.txt

[tirumal reddy]

On Wed, 20 Jan 2021 at 07:51, Qin Wu  wrote:

> Tiru:
>
> I am wondering whether section 4.2 “Encrypted DNS” should reference 7 of
> draft-richardson-opsawg-mud-iot-dns-considerations-03 for DNS
> recommendation.
>

Yes, I will update in the next revision. Thanks.

-Tiru


>
> -Qin
>
> *发件人:* OPSAWG [mailto:opsawg-boun...@ietf.org] *代表 *tirumal reddy
> *发送时间:* 2021年1月18日 12:51
> *收件人:* opsawg 
> *主题:* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-04.txt
>
>
>
> In this revised draft
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-04 Privacy
> Considerations section is updated to address comments from Michael.
>
>
>
> Further comments and suggestions are welcome.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> On Sun, 17 Jan 2021 at 17:22,  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
> Filename: draft-ietf-opsawg-mud-tls-04.txt
> Pages   : 34
> Date: 2021-01-17
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-04
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-04.txt

[tirumal reddy]

In this revised draft
https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-04 Privacy
Considerations section is updated to address comments from Michael.

Further comments and suggestions are welcome.

Cheers,
-Tiru

On Sun, 17 Jan 2021 at 17:22,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
> Filename: draft-ietf-opsawg-mud-tls-04.txt
> Pages   : 34
> Date: 2021-01-17
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-04
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03

[tirumal reddy]

I have reviewed the draft and support its adoption.

-Tiru

On Mon, 4 Jan 2021 at 23:36, Henk Birkholz 
wrote:

> Dear OPSAWG members,
>
> this starts a call for Working Group Adoption on
> https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03
> ending on Monday, January 25.
>
> As a reminder, this I-D describes ways to update (if possible) MUD URIs
> as specified in RFC8520 Manufacturer Usage Description (MUD) in a secure
> and acceptable manner.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call on draft-richardson-opsawg-mud-iot-dns-considerations-03

[tirumal reddy]

I support adoption of the draft. My initial comments below:

1)

Use of DoT to a local DNS recursive resolver is a preferred
choice, assuming that the trust anchor for the local DNS server can
be obtained, such as via [I-D.reddy-dprive-bootstrap-dns-server].

Comment> I would replace DoT with "Encrypted DNS connection"

2)
   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.

Comment> The threat is further minimized by the use of oblivous DNS
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-03 (see
https://blog.cloudflare.com/oblivious-dns/).

3)  IoT devices that reach out to the manufacturer at regular intervals
   to check for firmware updates are informing passive eavesdroppers of
   the existence of a specific manufacturer's device being present at
   the origin location.

Comment> Identifying the IoT device type empowers the attacker to launch
targeted attacks
to the IoT device (e.g., Attacker can advantage of the device
vulnerability).

4) IoT Devices should prefer doing DNS to the network provided DNS
servers.  Whether this is restricted to Classic DNS (Do53) or also
includes using DoT/DoH is a local decision, but a locally provided
DoT server SHOULD be used, as recommended by
[I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp].

Comment> ADD WG is currently only focusing on insecure discovery mechanisms
like DHCP/RA (https://tools.ietf.org/html/draft-btw-add-home-10) and DNS
based discovery mechanisms (
https://tools.ietf.org/html/draft-pauly-add-deer-00). Secure discovery of
network provided DoH/DoT resolver is possible using the mechanisms
discussed in
https://tools.ietf.org/html/draft-reddy-add-enterprise-00#section-4.

5) Wildcard certificates are also commonly available which allowed for an
   infinite number of possible names.

Comment> https://tools.ietf.org/html/rfc6125#section-6.4.3 does not
recommend the use of wildcard certificates.

6)
  Where the solution is more complex is when the MUD controller is
   located elsewhere in an Enteprise, or remotely in a cloud such as
   when a Software Defines Network (SDN) is used to manage the ACLs.
   The DNS servers for a particular device may not be known to the MUD
   controller, nor the MUD controller be even permitted to make recusive
   queries that server if it is known.  In this case, additional
   installation specific mechanisms are probably needed to get the right
   view of DNS.

Comment> The MUD controller can program the Enterprise DNS resolver to
enforce the DNS
filtering rules. DNS resolvers can enforce device specific filtering.

Cheers,
-Tiru

On Mon, 4 Jan 2021 at 23:34, Henk Birkholz 
wrote:

> Dear OPSAWG members,
>
> this starts a call for Working Group Adoption on
>
> https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03
> ending on Monday, January 25.
>
> As a reminder, this I-D describes potential issues and concerns
> regarding the use of DNS names and IP addressed with RFC8520
> Manufacturer Usage Description (MUD) in support of device access.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-03.txt

[tirumal reddy]

Hi all,

This revision https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-03
addresses
comments from Med.
Further comments and suggestions are welcome.

Cheers,
-Tiru

On Mon, 2 Nov 2020 at 11:15,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
> Filename: draft-ietf-opsawg-mud-tls-03.txt
> Pages   : 34
> Date: 2020-11-01
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-03
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt

[tirumal reddy]

On Fri, 23 Oct 2020 at 18:01,  wrote:

> Hi Tiru,
>
>
>
> Thanks.
>
>
>
> I sent you a PR (https://github.com/tireddy2/MUD-TLS-profile/pull/5/files)
>

Thanks, merged PR.

Cheers,
-Tiru

>
>
> Cheers,
>
> Med
>
>
>
> *De :* tirumal reddy [mailto:kond...@gmail.com]
> *Envoyé :* vendredi 23 octobre 2020 14:26
> *À :* BOUCADAIR Mohamed TGI/OLN 
> *Cc :* Michael Richardson ; opsawg  >
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt
>
>
>
> On Thu, 22 Oct 2020 at 17:17,  wrote:
>
> Re-,
>
>
>
> Yes, I know.
>
>
>
> This is why I suggested it to be added on TLS-related specs. That’s
> superior to the current approach in the draft.
>
>
>
> I have updated the draft to discuss the rationale for adding a new
> registry, please see Section 5.3 in
> https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-ietf-opsawg-mud-tls-03.txt
>
>
>
> -Tiru
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* tirumal reddy [mailto:kond...@gmail.com]
> *Envoyé :* jeudi 22 octobre 2020 13:34
> *À :* BOUCADAIR Mohamed TGI/OLN 
> *Cc :* Michael Richardson ; opsawg  >
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt
>
>
>
> On Thu, 22 Oct 2020 at 14:39,  wrote:
>
> Hi Tiru, all,
>
>
>
> Ideally, the version registry should be maintained and updated by the
> relevant (D)TLS specs. This can be part of draft-ietf-tls-dtls13 or
> draft-ietf-tls-rfc8446bis-00
> <https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#section-11>.
>
>
>
> TLS does not define any version specific registry maintained by IANA. In
> TLS 1.3, version support is determined by the presence of
> supported_versions extension and the version field should have the value 
> 0x0304.
> In prior versions, legacy_version field is used to indicate older TLS
> version (e.g., 0x0304 is used to indicate TLS 1.2).
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG [mailto:opsawg-boun...@ietf.org] *De la part de* tirumal
> reddy
> *Envoyé :* jeudi 22 octobre 2020 08:43
> *À :* Michael Richardson 
> *Cc :* opsawg 
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt
>
>
>
> On Wed, 21 Oct 2020 at 22:24, Michael Richardson 
> wrote:
>
>
> tirumal reddy  wrote:
> > a) Added two new YANG modules iana-tls-profile ((D)TLS parameters and
> > (D)TLS versions) and ietf-mud-tls (MUD (D)TLS Profile Extension).
>
> I browsed through the differences.
>
> Do I understand that iana-tls-profile would be updated by IANA as they
> handed
> out TLS protocol numbers ?
>
>
>
> Yes, iana-tls-profile will be updated by IANA. The procedure to update
> (D)TLS versions/parameters registries and iana-tls-profile is explained in
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-02#section-10.1
>
>
>
> Cheers,
>
> -Tiru
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>
> Thank you.
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant suscept

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt

[tirumal reddy]

On Thu, 22 Oct 2020 at 17:17,  wrote:

> Re-,
>
>
>
> Yes, I know.
>
>
>
> This is why I suggested it to be added on TLS-related specs. That’s
> superior to the current approach in the draft.
>

I have updated the draft to discuss the rationale for adding a new
registry, please see Section 5.3 in
https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-ietf-opsawg-mud-tls-03.txt

-Tiru

>
>
> Cheers,
>
> Med
>
>
>
> *De :* tirumal reddy [mailto:kond...@gmail.com]
> *Envoyé :* jeudi 22 octobre 2020 13:34
> *À :* BOUCADAIR Mohamed TGI/OLN 
> *Cc :* Michael Richardson ; opsawg  >
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt
>
>
>
> On Thu, 22 Oct 2020 at 14:39,  wrote:
>
> Hi Tiru, all,
>
>
>
> Ideally, the version registry should be maintained and updated by the
> relevant (D)TLS specs. This can be part of draft-ietf-tls-dtls13 or
> draft-ietf-tls-rfc8446bis-00
> <https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#section-11>.
>
>
>
> TLS does not define any version specific registry maintained by IANA. In
> TLS 1.3, version support is determined by the presence of
> supported_versions extension and the version field should have the value 
> 0x0304.
> In prior versions, legacy_version field is used to indicate older TLS
> version (e.g., 0x0304 is used to indicate TLS 1.2).
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG [mailto:opsawg-boun...@ietf.org] *De la part de* tirumal
> reddy
> *Envoyé :* jeudi 22 octobre 2020 08:43
> *À :* Michael Richardson 
> *Cc :* opsawg 
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt
>
>
>
> On Wed, 21 Oct 2020 at 22:24, Michael Richardson 
> wrote:
>
>
> tirumal reddy  wrote:
> > a) Added two new YANG modules iana-tls-profile ((D)TLS parameters and
> > (D)TLS versions) and ietf-mud-tls (MUD (D)TLS Profile Extension).
>
> I browsed through the differences.
>
> Do I understand that iana-tls-profile would be updated by IANA as they
> handed
> out TLS protocol numbers ?
>
>
>
> Yes, iana-tls-profile will be updated by IANA. The procedure to update
> (D)TLS versions/parameters registries and iana-tls-profile is explained in
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-02#section-10.1
>
>
>
> Cheers,
>
> -Tiru
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>
> Thank you.
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt

[tirumal reddy]

On Thu, 22 Oct 2020 at 14:39,  wrote:

> Hi Tiru, all,
>
>
>
> Ideally, the version registry should be maintained and updated by the
> relevant (D)TLS specs. This can be part of draft-ietf-tls-dtls13 or
> draft-ietf-tls-rfc8446bis-00
> <https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#section-11>.
>

TLS does not define any version specific registry maintained by IANA. In
TLS 1.3, version support is determined by the presence of
supported_versions extension and the version field should have the
value 0x0304.
In prior versions, legacy_version field is used to indicate older TLS
version (e.g., 0x0304 is used to indicate TLS 1.2).

Cheers,
-Tiru

>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG [mailto:opsawg-boun...@ietf.org] *De la part de* tirumal
> reddy
> *Envoyé :* jeudi 22 octobre 2020 08:43
> *À :* Michael Richardson 
> *Cc :* opsawg 
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt
>
>
>
> On Wed, 21 Oct 2020 at 22:24, Michael Richardson 
> wrote:
>
>
> tirumal reddy  wrote:
> > a) Added two new YANG modules iana-tls-profile ((D)TLS parameters and
> > (D)TLS versions) and ietf-mud-tls (MUD (D)TLS Profile Extension).
>
> I browsed through the differences.
>
> Do I understand that iana-tls-profile would be updated by IANA as they
> handed
> out TLS protocol numbers ?
>
>
>
> Yes, iana-tls-profile will be updated by IANA. The procedure to update
> (D)TLS versions/parameters registries and iana-tls-profile is explained in
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-02#section-10.1
>
>
>
> Cheers,
>
> -Tiru
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt

[tirumal reddy]

On Wed, 21 Oct 2020 at 22:24, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> > a) Added two new YANG modules iana-tls-profile ((D)TLS parameters and
> > (D)TLS versions) and ietf-mud-tls (MUD (D)TLS Profile Extension).
>
> I browsed through the differences.
>
> Do I understand that iana-tls-profile would be updated by IANA as they
> handed
> out TLS protocol numbers ?
>

Yes, iana-tls-profile will be updated by IANA. The procedure to update
(D)TLS versions/parameters registries and iana-tls-profile is explained in
https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-02#section-10.1

Cheers,
-Tiru

>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-02.txt

[tirumal reddy]

Hi all,

Revised draft https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-02
addresses comments from Mohamed Boucadair.

Main changes are listed below:

a) Added two new YANG modules iana-tls-profile ((D)TLS parameters and
(D)TLS versions) and ietf-mud-tls (MUD (D)TLS Profile Extension).
b) updated to YANG module ietf-acl-tls to use iana-tls-profile
c) Added rules to update iana-tls-profile, and created registries for
(D)TLS versions and (D)TLS parameters.

Further comments and suggestions are welcome.

Cheers,
-Tiru

On Wed, 21 Oct 2020 at 14:54,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
> Filename: draft-ietf-opsawg-mud-tls-02.txt
> Pages   : 32
> Date: 2020-10-21
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-02
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-01.txt

[tirumal reddy]

Revised draft https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-01
addresses several comments from OPSAWG and TLS WGs.



Main changes are listed below:


1) New Section 6 discusses MUD TLS profile processing rules to handle
protocol ossification

2) Added several examples to Section 6 and Section 7

3) Removed the GREASE supported flag in the YANG module and the MUD TLS
profile does not include GREASE values.

3) Updated YANG module.



Further comments and suggestions are welcome.



Cheers,

-Tiru


On Mon, 5 Oct 2020 at 13:57,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : Manufacturer Usage Description (MUD) (D)TLS
> Profiles for IoT Devices
> Authors : Tirumaleswar Reddy
>   Dan Wing
>   Blake Anderson
> Filename: draft-ietf-opsawg-mud-tls-01.txt
> Pages   : 24
> Date: 2020-10-05
>
> Abstract:
>This memo extends the Manufacturer Usage Description (MUD)
>specification to incorporate (D)TLS profile parameters.  This allows
>a network security service to identify unexpected (D)TLS usage, which
>can indicate the presence of unauthorized software or malware on an
>endpoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-01
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[tirumal reddy]

On Mon, 28 Sep 2020 at 12:33, Eliot Lear  wrote:

> Tiru
>
> On 28 Sep 2020, at 08:52, tirumal reddy  wrote:
>
>>
>> Not necessarily.  That is a matter of signaling between the CPE and the
>> ISP.
>>
>
> No, the special use domain name (SUDN) does not require any update to the
> CPE. The signaling from the endpoint is resolved by the ISP DNS recursive
> server and, it is not between the CPE and the ISP.
>
>
> All I am saying is this:
>
>  ,.  ,---.   ,--.
>  |Endpoint|  |CPE|   |ISPDNS|
>  `---+'  `-+-'   `--+---'
>  |  1 A/ Query  |
>  | ->
>  | ||
>  |2 Response(A/)|
>  | <-
>  | ||
>  | |3 add ACL/TR.369|
>  | | or similar |
>  | |<
>  ,---+.  ,-+-.   ,--+---.
>  |Endpoint|  |CPE|   |ISPDNS|
>  `'  `---'   `--'
>
> You can substitute “ISPDNS” for whoever offers the CPE (like
> Google/Eero/etc, so long as the DNS infra and CPE know about one another
> and agree on a control channel).
>

Yes, that should work for managed CPE. ISPs and security vendors want to
host a encrypted DNS forwarder on the home router itself, see
https://tools.ietf.org/html/draft-box-add-requirements-00#section-3.1.2 and
https://tools.ietf.org/html/draft-campling-operator-observations-00

-Tiru


>
> Eliot
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[tirumal reddy]

On Sun, 27 Sep 2020 at 04:32, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> >> tirumal reddy  wrote:
> >> > +1.  The problem is not just with public resolvers but also with
> >> > designated resolvers. The IoT device supporting MUD must use the
> >> > encrypted DNS server discovered in the attached network.
> >>
> >> Yes-ish.
> >>
> >> I don't think that we have to mandate use of encrypted DNS servers,
> >> as long as it's the ones on the attached network.
> >>
>
> > In the home network use case, if the CPE does not support an
> encrypted DNS
> > forwarder, endpoint will discover and use the ISP encrypted DNS
> recursive
> > server. The CPE will no longer be able to enforce MUD rules. For
> instance,
> > Firefox can discover and use Comcast Encrypted DNS recursive server,
> see
> > https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.
>
> It's reasonable that Firefox might do that, but I don't see why IoT devices
> should follow suit, and that's the point of this document.


> Except in some very niche digital signage and kiosk use, I don't think a
> MUD
> file would be appropriate for a general-purpose browser.
>

I quoted Firefox as an example, the proposed mechanism of using SUDN to
discover the ISP encrypted DNS resolver is generic and not specific to
browsers. If the endpoint cannot discover the local encrypted DNS server
(hosted on the CPE) using DHCP/RA, the endpoint will fallback to using SUDN
to discover the one hosted by the ISP.

-Tiru


>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[tirumal reddy]

On Sat, 26 Sep 2020 at 14:39, Eliot Lear  wrote:

> Hi Tiru
>
> On 26 Sep 2020, at 09:39, tirumal reddy  wrote:
>
> In the home network use case, if the CPE does not support an encrypted DNS
> forwarder, endpoint will discover and use the ISP encrypted DNS recursive
> server. The CPE will no longer be able to enforce MUD rules. For instance,
> Firefox can discover and use Comcast Encrypted DNS recursive server, see
> https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.
>
>
>
> Not necessarily.  That is a matter of signaling between the CPE and the
> ISP.
>

No, the special use domain name (SUDN) does not require any update to the
CPE. The signaling from the endpoint is resolved by the ISP DNS recursive
server and, it is not between the CPE and the ISP.

-Tiru

>
> Eliot
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[tirumal reddy]

On Fri, 25 Sep 2020 at 23:11, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> > +1.  The problem is not just with public resolvers but also with
> > designated resolvers. The IoT device supporting MUD must use the
> > encrypted DNS server discovered in the attached network.
>
> Yes-ish.
>
> I don't think that we have to mandate use of encrypted DNS servers,
> as long as it's the ones on the attached network.
>

In the home network use case, if the CPE does not support an encrypted DNS
forwarder, endpoint will discover and use the ISP encrypted DNS recursive
server. The CPE will no longer be able to enforce MUD rules. For instance,
Firefox can discover and use Comcast Encrypted DNS recursive server, see
https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.


>
> My take is that it is better to use Do53 across the local LAN than public
> DoH
> server.   If the IoT device can be convinced to use the local DoT server,
> great.
> But, your documents in ADD are clearly trying to get there, but we aren't
> there yet.
>

In the interim ADD session 2, the consensus is to use DHCP/RA to discover
the local encrypted DNS server.
https://tools.ietf.org/html/draft-btw-add-home-09 extends DHCP/RA and it
also discusses hosting a DoH/DoT forwarder on the home router.

-Tiru


>
> I've been looking for a YANG module that would allow for explicit
> management
> of "/etc/resolv.conf" on a device.  If there is one, I don't know where it
> would be.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[tirumal reddy]

+1.
The problem is not just with public resolvers but also with designated
resolvers. The IoT device supporting MUD must use the encrypted DNS server
discovered in the attached network.

-Tiru

On Thu, 24 Sep 2020 at 21:53, Eliot Lear 
wrote:

>
>
> > On 24 Sep 2020, at 17:20, Michael Richardson 
> wrote:
> >
> >
> > I would like the OPSAWG to consider adopting this MUD related document.
> > It changes no bits on the wire changes to MUD or semantic changes (like
> my
> > other document), rather this is guidance to IoT manufacturers.
> >
>
> I’d like that too.
>
> Eliot
>
> --
> Mud mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mud
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Ben,

Please see inline

On Tue, 22 Sep 2020 at 20:45, Ben Schwartz  wrote:

> I'm not able to understand the new text in Section 6.  Are you saying that
> clients MUST include all the listed extensions/features, but MAY also
> include extensions/features not listed in the MUD profile?  So the MUD
> profile only acts as a "minimum" set of features?
>

Section 6 discusses the firewall behaviour when it sees a) known
extensions/features in a TLS session but not specified in the MUD profile
b) unknown extensions/features in a TLS session either specified or not
specified in the MUD profile c) updated MUD profile specifying
extensions/features  not supported by the firewall.

If the client supports new features/extensions but not yet added in the
YANG module, it can be updated using expert review or specification
required registration procedure, discussed in
https://tools.ietf.org/html/rfc8126.

Cheers,
-Tiru


>
> On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy  wrote:
>
>> On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:
>>
>>>
>>>
>>> > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
>>> >
>>> > On Fri, 11 Sep 2020 12:32:03 +0530
>>> > tirumal reddy  wrote:
>>> >
>>> >> The MUD URL is encrypted and shared only with the authorized
>>> >> components in the network. An  attacker cannot read the MUD URL and
>>> >> identify the IoT device. Otherwise, it provides the attacker with
>>> >> guidance on what vulnerabilities may be present on the IoT device.
>>> >
>>> > RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
>>> > over LLDP without - so far as I was able to see - any mechanism by
>>> which
>>> > it should be meaningfully "encrypted" as to prevent an attacker on your
>>> > network from reading it.
>>>
>>> That’s a bit of an overstatement.  RFC 8520 specifies a component
>>> architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/
>>> certificate).  Two other mechanisms have already been developed (QR code,
>>> Device Provisioning Protocol), and a 3rd new method is on the way for
>>> cellular devices.
>>>
>>> I would not universally claim that a MUD URL is secret but neither would
>>> I claim it is not.  The management tooling will know which is which, as
>>> will the manufacturer, and can make decisions accordingly.
>>>
>>> This having been said, it seems to me we are off on the wrong foot
>>> here.  The serious argument that needs to be addressed is Ben’s and EKR's.
>>> We have to be careful about ossification.
>>>
>>
>> In order to address the comments on ossification, we added a new section
>> 6 to explain the rules to processing the MUD (D)TLS rules to handle unknown
>> TLS parameters and updated Section 10 to enable faster update to the YANG
>> module. Please see
>> https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt
>>
>> -Tiru
>> ___
>> TLS mailing list
>> t...@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Agreed to get early SecDir review. Published draft-ietf-opsawg-mud-tls
without any changes, we will address the comments from both the WGs in the
next revision.

Cheers,
-Tiru

On Tue, 22 Sep 2020 at 18:45, Joe Clarke (jclarke)  wrote:

> The call for adoption has closed.  It has not been without discussion to
> be sure.  There have been concerns expressed from the TLS working group
> that it might benefit malware authors and that it could lead to
> “ossification” in use of the TLS protocol.
>
> That said, there has been considerable support expressed for (and active
> willingness to work in) moving this work forward.  Therefore, this document
> has been adopted by the opsawg working group.  The authors have already
> been active in addressing some concerns brought up during the CFA, and the
> chairs encourage the authors and those interested in the progression of
> this work to continue to work with the TLS WG to fully shore up the text
> and YANG module.
>
> Additionally, it might be good to get a more formal early review of this
> work from SecDir so that the WG can focus on additional items required to
> move the work forward.
>
> Authors, please rename this draft, draft-ietf-opsawg-mud-tls and resubmit
> it to DataTracker as a -00.  DO NOT change any other text.  Within DT, mark
> this draft as replacing draft-reddy-opsawg-mud-tls.
>
> Thanks.
>
> Joe
>
> > On Sep 2, 2020, at 11:05, Joe Clarke (jclarke)  40cisco@dmarc.ietf.org> wrote:
> >
> > Hello, opsawg.  This draft as underwent a number of revisions based on
> reviews and presentations at the last few IETF meetings.  The authors feel
> they have addressed the issues and concerns from the WG in their latest
> posted -05 revision.  As a reminder, this document describes how to use
> (D)TLS profile parameters with MUD to expose potential unauthorized
> software or malware on an endpoint.
> >
> > To that end, this serves as a two-week call for adoption for this work.
> Please reply with your support and/or comments by September 16, 2020.
> >
> > Thanks.
> >
> > Joe and Tianran
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:

>
>
> > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
> >
> > On Fri, 11 Sep 2020 12:32:03 +0530
> > tirumal reddy  wrote:
> >
> >> The MUD URL is encrypted and shared only with the authorized
> >> components in the network. An  attacker cannot read the MUD URL and
> >> identify the IoT device. Otherwise, it provides the attacker with
> >> guidance on what vulnerabilities may be present on the IoT device.
> >
> > RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> > over LLDP without - so far as I was able to see - any mechanism by which
> > it should be meaningfully "encrypted" as to prevent an attacker on your
> > network from reading it.
>
> That’s a bit of an overstatement.  RFC 8520 specifies a component
> architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/
> certificate).  Two other mechanisms have already been developed (QR code,
> Device Provisioning Protocol), and a 3rd new method is on the way for
> cellular devices.
>
> I would not universally claim that a MUD URL is secret but neither would I
> claim it is not.  The management tooling will know which is which, as will
> the manufacturer, and can make decisions accordingly.
>
> This having been said, it seems to me we are off on the wrong foot here.
> The serious argument that needs to be addressed is Ben’s and EKR's.  We
> have to be careful about ossification.
>

In order to address the comments on ossification, we added a new section 6
to explain the rules to processing the MUD (D)TLS rules to handle unknown
TLS parameters and updated Section 10 to enable faster update to the YANG
module. Please see
https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt

-Tiru
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

On Thu, 17 Sep 2020 at 01:38, Nick Harper  wrote:

>
>
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy  wrote:
>
>> Hi Nick,
>>
>> Please see inline
>>
>> On Wed, 16 Sep 2020 at 06:00, Nick Harper  wrote:
>>
>>> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
>>>
>>> The grease_extension parameter shouldn't exist, and there should be no
>>> special handling for GREASE values. GREASE doesn't need to be mentioned in
>>> this draft, except to say that a client may send values (cipher suites,
>>> extensions, named groups, signature algorithms, versions, key exchange
>>> modes, ALPN identifiers, etc.) that are unknown to the middlebox and that
>>> the middlebox MUST NOT reject connections with values unknown to the
>>> middlebox.
>>>
>>
>> The grease_extension parameter in the YANG model is a "boolean" type to
>> indicate whether the GREASE values are offered by the client or not.  The
>> MUD YANG model does not convey the GREASE values.
>>
>>
> This is still problematic.
>
> Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to
> check that their peers correctly ignore unknown values (instead of closing
> the connection). If a device special-cases GREASE values when processing
> TLS messages, that device has completely missed the purpose of GREASE and
> is likely to cause interoperability failures when in the future it sees a
> TLS message that contains a new extension/cipher suite/etc. that isn't a
> GREASE value.
>
> The IETF should not be encouraging devices to special-case GREASE values.
> I can see no use of the grease_extension parameter in the YANG model that
> does not involve special-casing GREASE values. Hence it needs to be removed.
>

Got it, Thanks. Removed the grease_extension parameter from the YANG module
and added the following text:

   GREASE [RFC8701] sends random values on TLS parameters to ensure
   future extensibility of TLS extensions.  Such GREASE values might be
   extended to other TLS parameters.  Thus, the (D)TLS profile
   parameters defined in the YANG module by this document MUST NOT
   include the GREASE values for extension types, named groups,
   signature algorithms, (D)TLS versions, pre-shared key exchange modes,
   cipher suites and for any other TLS parameters defined in future
   RFCs.

-Tiru
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Sandeep,

Please see inline

On Wed, 16 Sep 2020 at 02:35, Sandeep Rao  wrote:

> Hi,
>
>
> I have read this document and its support adoption here.
>
>
> There’s one comment,  maybe the authors can clarify this in the draft.
>
>
> I believe though not widely used, was recently involved in a talk about
> usefulness of TLS session resumption in IoT implementations to improve
> session establishment efficiency and speed.   As the resumption handshake
> would not carry the typical ClientHello parameters , how would the MUD IoT
> firewall profile such legitimate ingress with no specific profile
> parameters or indications in the handshake ?
>

The client does not know whether the server will honor the ticket or not,
it will include all the ClientHello parameters (see
https://tools.ietf.org/html/rfc5077 and
https://tools.ietf.org/html/rfc8446#section-2.2) to allow the server to
decline the resumption and fall back to a full handshake.


> Probably this is expressed in ‘mud-tls-profile’ with an attribute such as
> “sessionTicket” : "T/F" or  in “extension-types” indicating the
> possibility of such behaviour of the IoT device and let Firewall handle it
> in its implementation.  Will help to get some clarity around this in the
> document.
>

In TLS 1.2, SessionTicket is an extension (see value 35 in
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml).
If the client supports this extension, it will be included in the
"extension-types" list defined in the YANG module.

TLS 1.3 obsoletes the session resumption mechanism in TLS 1.2 and defines a
new session resumption mechanism in the base TLS 1.3 spec (RFC8446) itself.
In other words, TLS 1.3 clients will always support session resumption
(unlike TLS 1.2 clients).

Cheers,
-Tiru


> Thanks
>
> -Sandeep
>
>
>>
>> -- Forwarded message -
>> From: Joe Clarke (jclarke) 
>> Date: Wed, 2 Sep 2020 at 20:36
>> Subject: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
>> To: opsawg 
>>
>>
>> Hello, opsawg.  This draft as underwent a number of revisions based on
>> reviews and presentations at the last few IETF meetings.  The authors feel
>> they have addressed the issues and concerns from the WG in their latest
>> posted -05 revision.  As a reminder, this document describes how to use
>> (D)TLS profile parameters with MUD to expose potential unauthorized
>> software or malware on an endpoint.
>>
>> To that end, this serves as a two-week call for adoption for this work.
>> Please reply with your support and/or comments by September 16, 2020.
>>
>> Thanks.
>>
>> Joe and Tianran
>> ___
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

On Thu, 10 Sep 2020 at 21:21, Michael Richardson 
wrote:

> On 2020-09-04 10:18 a.m., mohamed.boucad...@orange.com wrote:
> > Hi all,
> ...
> > It would be fair to include some of the limitations of the proposed
> approach (e.g., IoT devices that are not maintained).
>
> IoT devices which never get software updates would benefit greatly from
> additional protection that MUD provides.  A MUD profile for such a
> device would have to be created by a third party, and one way to do this
> is by observation of current traffic.That could certainly include
> TLS parameters observed.
> There are multiple efforts in this direction, and additional
> coordination is probably desirable.
>

That is exactly what we are working on till we get support from IoT
manufacturers.


>
> Since the device is not getting updates, it won't be changing it's TLS
> library, and so the mechanisms that are described in this document will
> be even MORE effective.   So I'm not sure what limitations you are
> thinking about here.
>
> The real risk is that the device suddenly receives an update, and since
> the MUD file is not from the manufacturer, that the device now sets of
> alarms as the MUD file has not been updated.
>

To handle this scenario, the default action is not to block the TLS session
but to export the network telemetry including TLS metadata for anomaly
detection using machine learning techniques (similar to
https://arxiv.org/pdf/1607.01639.pdf).

Cheers,
-Tiru


>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Qin,

Thanks for the support and review. Please see line

On Mon, 7 Sep 2020 at 07:37, Qin Wu  wrote:

> Support adoption of this work.
> I have a few comments which I would like authors to consider:
> 1. Module name I strange, should not include surname and WG name in the
> standard module name, suggest to change it from
> reddy-opsawg-mud-tls-profile into ietf-mud-tls-profile
>

Sure, will change after the draft is adopted by the WG.


> 2. Can we still see this module as "ietf-mud" extension module? since
> reddy-opsawg-mud-tls-profile is not augmentation of ietf-mud module any
> more in v-03
>

It specifies an extension to ACL similar to the way RFC8520 augments ACL.
"ietf-mud" module can contain the extended ACL with MUD (D)TLS profile. For
example, see
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-6



> 3. Section 3 said:
> "
>The compromised IoT devices are typically used for launching DDoS
>attacks (Section 3 of [RFC8576]).  Some of the DDoS attacks like
>Slowloris and Transport Layer Security (TLS) re-negotiation can be
>detected by observing the (D)TLS profile parameters.  For example,
>the victim's server certificate need not be signed by the same
>certifying authorities trusted by the IoT device.
> "
> How do you make sure you can detect DDoS attacks by only observing DTLS
> profile parameters? What about Legitimate IoT device's server certificate
> is also signed by the same certifying authorities?
> You may block legitimate IoT devices who did TLS re-negotiation?
>

MUD (D)TLS profile will not identify TLS renegotiation attack but can
identify the IoT device is not supposed to communicate with the victim
server. For example, the victim's server certificate need not be signed by
the same certifying authorities trusted by the IoT device.


> 4. Section 4.1 said:
> "
> In other words, the
>scope of middle-box acting as a (D)TLS proxy is restricted to
>Enterprise network owning and managing the IoT devices.
> "
> How do I make sure middle box acting as DTLS proxy is not man in the
> middle attack? Is there mutual authentication mechanism which can be used?
> How do I authenticate middle box is a trusted entity?
>

Middlebox cannot act as a TLS proxy unless the IoT device is securely
provisioned with the middle-box's CA certificate as Explicit Trust Anchor
database entry to validate the server certificate. For example, the
provisioning can be done using an IoT device management tool (see
https://tools.ietf.org/html/draft-wang-tls-proxy-best-practice-00#section-4.1
).


> 5. Section 4.2 said:
> "
>If an IoT device is pre-configured to use
>public DNS-over-(D)TLS or DNS-over-HTTPS servers, that middle-box
>needs to act as a DNS-over-TLS or DNS-over-HTTPS proxy and replace
>the esni_keys in the ESNI record with the middle box's esni_keys.
> "
> Same question is applicable to the quoted text? How do I make sure middle
> box is not a man in the middle attack?
>

Same as above.

Cheers,
-Tiru


>
> -Qin
> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
> 发送时间: 2020年9月2日 23:06
> 收件人: opsawg 
> 主题: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
>
> Hello, opsawg.  This draft as underwent a number of revisions based on
> reviews and presentations at the last few IETF meetings.  The authors feel
> they have addressed the issues and concerns from the WG in their latest
> posted -05 revision.  As a reminder, this document describes how to use
> (D)TLS profile parameters with MUD to expose potential unauthorized
> software or malware on an endpoint.
>
> To that end, this serves as a two-week call for adoption for this work.
> Please reply with your support and/or comments by September 16, 2020.
>
> Thanks.
>
> Joe and Tianran
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Nick,

Please see inline

On Wed, 16 Sep 2020 at 06:00, Nick Harper  wrote:

> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
>
> The grease_extension parameter shouldn't exist, and there should be no
> special handling for GREASE values. GREASE doesn't need to be mentioned in
> this draft, except to say that a client may send values (cipher suites,
> extensions, named groups, signature algorithms, versions, key exchange
> modes, ALPN identifiers, etc.) that are unknown to the middlebox and that
> the middlebox MUST NOT reject connections with values unknown to the
> middlebox.
>

The grease_extension parameter in the YANG model is a "boolean" type to
indicate whether the GREASE values are offered by the client or not.  The
MUD YANG model does not convey the GREASE values.


> (This can be stated without mentioning GREASE specifically.)
>
> There is also an issue where this draft does not describe how an observer
> identifies whether a TLS ClientHello is compliant with a MUD profile.
>

For example, an alert could be triggered to quarantine and remediate the
compromised device, and will update the draft to clarify.

-Tiru


>
> On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd  wrote:
>
>> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
>>  wrote:
>> >
>> >
>> >
>> > My concern is not with "new extensions" per se.  The hidden assumption
>> here is that "extensions" are the only way TLS can evolve.  In fact, future
>> TLS versions are not constrained to evolve in any particular way.  For
>> example, future versions can introduce entirely new messages in the
>> handshake, or remove messages that are currently visible in the handshake.
>> QUIC is arguably just an extreme version of this observation.
>> >
>> >
>> > I understand.  I used TLS extensions merely as an example.
>>
>> There is no reason that a firewall should expect to parse TLS 1.4. TLS
>> 1.3 had to go through significant hoops due to middleboxes that
>> assumed they could see into everything like it was 1.2. This easily
>> added a year to the development time. The final hunt for incompatible
>> devices involved attempting to purchase samples, with no real
>> guarantee that they would find an intolerant device. Encouraging this
>> sort of behavior is a bad idea IMHO, as it will substantially burden
>> the TLS WG when designing TLS 1.4 in all sorts of unexpected ways.
>>
>> >
>> >
>> > Even within the realm of ClientHello extensions, there is significant
>> inflexibility here.  For example, consider the handling of GREASE
>> extensions.  GREASE uses a variety of reserved extension codepoints,
>> specifically to make sure that no entity is attempting to restrict use of
>> unrecognized extensions.  This proposal therefore has to add a flag
>> declaring whether the client uses GREASE, because otherwise the set of
>> extensions is dynamic, and the number of potential codepoints is
>> impractically large.  Any change to the way GREASE selects and rotates
>> extension codepoints would therefore require a revision of this YANG model
>> first.  There has also been discussion of adding GREASE-type behavior to
>> the "supported_versions" extension; that would similarly require a revised
>> YANG model here.
>> >
>> >
>> > Probably greasing is something that needs a certain special handling.
>> Indeed that’s a form of fingerprinting (greases field XYZ).
>>
>> The whole point of grease is keeping extensions open. Coding special
>> handling defeats the purpose.
>>
>> Sincerely,
>> Watson Ladd
>>
>> >
>> > Eliot
>>
>> ___
>> TLS mailing list
>> t...@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

On Tue, 15 Sep 2020 at 18:39, Eliot Lear  wrote:

>
>
> My concern is not with "new extensions" per se.  The hidden assumption
> here is that "extensions" are the only way TLS can evolve.  In fact, future
> TLS versions are not constrained to evolve in any particular way.  For
> example, future versions can introduce entirely new messages in the
> handshake, or remove messages that are currently visible in the handshake.
> QUIC is arguably just an extreme version of this observation.
>
>
> I understand.  I used TLS extensions merely as an example.
>
>
> Even within the realm of ClientHello extensions, there is significant
> inflexibility here.  For example, consider the handling of GREASE
> extensions.  GREASE uses a variety of reserved extension codepoints,
> specifically to make sure that no entity is attempting to restrict use of
> unrecognized extensions.  This proposal therefore has to add a flag
> declaring whether the client uses GREASE, because otherwise the set of
> extensions is dynamic, and the number of potential codepoints is
> impractically large.  Any change to the way GREASE selects and rotates
> extension codepoints would therefore require a revision of this YANG model
> first.  There has also been discussion of adding GREASE-type behavior to
> the "supported_versions" extension; that would similarly require a revised
> YANG model here.
>
>
> Probably greasing is something that needs a certain special handling.
> Indeed that’s a form of fingerprinting (greases field XYZ).
>

Yes, GREASE requires special handling. The YANG model uses a flag to define
whether the client supports GREASE or not. The MUD TLS profile does not
advertise the GREASE values (see
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-5).

-Tiru


>
> Eliot
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

On Fri, 11 Sep 2020 at 16:11, Nick Lamb  wrote:

> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy  wrote:
>
> > The MUD URL is encrypted and shared only with the authorized
> > components in the network. An  attacker cannot read the MUD URL and
> > identify the IoT device. Otherwise, it provides the attacker with
> > guidance on what vulnerabilities may be present on the IoT device.
>
> RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> over LLDP without - so far as I was able to see - any mechanism by which
> it should be meaningfully "encrypted" as to prevent an attacker on your
> network from reading it.
>

RFC 8520 allows other means (see sections 1.5 and 1.8) like 802.1X (for
example, TEAP (it does not allow TLS cipher suites without encryption).
The client identity (certificate carrying the MUD URL) is encrypted and not
visible to eavesdroppers. Further, RFC8520 discusses IoT devices may not
even omit the URL. It recommends to use a proxy to retrieve the MUD file
for privacy reasons.

-Tiru


>
> Nick.
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Wei,

Thanks for the feedback. Please see inline

On Fri, 11 Sep 2020 at 09:43, Panwei (William) 
wrote:

> Hi authors, all,
>
> I've read the draft and I support adoption. This draft is useful for the
> network element, e.g., firewalls, to identity and prevent the unintended
> usage of (D)TLS encryption, which will help increase the security
> especially in the Enterprise networks. The unexpected usage of (D)TLS can
> include two aspects, one is using the old version or weak algorithms, the
> other is communicating with unauthorized servers. I'm glad to see this
> draft has covered these two aspects.
>
> Two comments:
> 1. The 'application-protocols' defined in the YANG module is string-type,
> can it be defined in a more accurate way, like port numbers or enumerations?


MUD ACL rules can already include port numbers (see
https://tools.ietf.org/html/rfc8520#section-9).


> Because I think different entities may have different interpretations of
> the strings.
> 2. It does be a problem if the updates of the MUD file can't follow the
> pace of the updates of IoT devices. This draft has considered this problem
> in some places, but I think it's better to outline this problem separately
> and systematically.
>

Sure, we will update the draft. You may also want to look into
https://datatracker.ietf.org/doc/html/draft-richardson-opsawg-mud-acceptable-urls-01,
it can help with rapidly updating the (D)TLS profile as new firmware is
installed.

Cheers,
-Tiru


>
> Regards & Thanks!
> Wei Pan
>
> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Joe Clarke
> (jclarke)
> Sent: Wednesday, September 2, 2020 11:06 PM
> To: opsawg 
> Subject: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
>
> Hello, opsawg.  This draft as underwent a number of revisions based on
> reviews and presentations at the last few IETF meetings.  The authors feel
> they have addressed the issues and concerns from the WG in their latest
> posted -05 revision.  As a reminder, this document describes how to use
> (D)TLS profile parameters with MUD to expose potential unauthorized
> software or malware on an endpoint.
>
> To that end, this serves as a two-week call for adoption for this work.
> Please reply with your support and/or comments by September 16, 2020.
>
> Thanks.
>
> Joe and Tianran
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Ben,

Please see inline

On Fri, 11 Sep 2020 at 07:05, Ben Schwartz  wrote:

> Thanks for highlighting this, Michael.  I don't support adoption of this
> draft, because I don't think it is fit-for-purpose.  Specifically, I think
> it is likely to provide a significant advantage to malware authors (the
> opposite of the intended effect).
>
> Currently, if a malware author wants to match the TLS characteristics of
> the host device, they have to do some work to characterize its TLS
> behavior.  This may be difficult, especially in the case of partial
> compromise, or for malware that targets a wide variety of hosts.  However,
> with this MUD module in place, the malware can read the TLS behavior right
> out of the MUD profile, and configure its behavior to match.
>

The MUD URL is encrypted and shared only with the authorized components in
the network. An  attacker cannot read the MUD URL and identify the IoT
device. Otherwise, it provides the attacker with guidance on what
vulnerabilities may be present on the IoT device.


> Note that, except in the case of TLS termination, the proxy cannot verify
> anything about the TLS session by observing it.  Just because a connection
> appears to use a particular SNI or certificate does not prove anything
> about the actual destination.
>

Yes, it is discussed in
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-4

Cheers,
-Tiru


>
> On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson 
> wrote:
>
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
>> > Hello, opsawg.  This draft as underwent a number of revisions based on
>> reviews and presentations at the last few IETF meetings.  The authors feel
>> they have addressed the issues and concerns from the WG in their latest
>> posted -05 revision.  As a reminder, this document describes how to use
>> (D)TLS profile parameters with MUD to expose potential unauthorized
>> software or malware on an endpoint.
>> >
>> > To that end, this serves as a two-week call for adoption for this
>> work.  Please reply with your support and/or comments by September 16, 2020.
>>
>> I have read the document in a number of different revisions, and I
>> support adoption.
>>
>> I have been concerned that this document codifies a kind of TLS snooping
>> by middle boxes which has in the past caused significant harm to
>> development of TLS. (In particular, TLS version negotiation has had to
>> evade existing middle box policies!)
>>
>> However,  this document seems to walk the fine line between causing
>> protocol ossification and providing real security.  To the extent that
>> it reduces the pressure by enterprises to invade the TLS encryption
>> envelope through use of Enterprise certificates [is there a term for the
>> activity describe in section 4.1? I wish there was] this document is a
>> very useful thing.
>>
>> I would like to suggest that upon adoption, that this document go
>> through a TLS WG review of some sort before OPSAWG does a WGLC.
>>
>>
>> ___
>> TLS mailing list
>> t...@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-05.txt

[tirumal reddy]

This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05
updates the (D)TLS profile to include GREASE and acceptable certificate
authorities. It also discusses encrypted SNI.

Comments and suggestions are more than welcome.

Cheers,
-Tiru

-- Forwarded message -
From: 
Date: Mon, 31 Aug 2020 at 12:37
Subject: New Version Notification for draft-reddy-opsawg-mud-tls-05.txt
To: Tirumaleswar Reddy.K , Dan Wing ,
Blake Anderson 



A new version of I-D, draft-reddy-opsawg-mud-tls-05.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-opsawg-mud-tls
Revision:   05
Title:  MUD (D)TLS profiles for IoT devices
Document date:  2020-08-30
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-05.txt
Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:   https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-05

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to incorporate
   (D)TLS profile parameters.  This allows a network element to identify
   unexpected (D)TLS usage, which can indicate the presence of
   unauthorized software or malware on an endpoint.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-03.txt

[tirumal reddy]

This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-03
addresses comments from Michael.
We look forward to further comments and suggestions.

Cheers,
-Tiru

-- Forwarded message -
From: 
Date: Wed, 29 Jan 2020 at 18:12
Subject: New Version Notification for draft-reddy-opsawg-mud-tls-03.txt
To: Tirumaleswar Reddy.K , Dan Wing ,
Blake Anderson 



A new version of I-D, draft-reddy-opsawg-mud-tls-03.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-opsawg-mud-tls
Revision:   03
Title:  MUD (D)TLS profiles for IoT devices
Document date:  2020-01-29
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-03.txt
Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:   https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-03

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to incorporate
   (D)TLS profile parameters.  This allows a network element to identify
   unexpected (D)TLS usage, which can indicate the presence of
   unauthorized software or malware on an endpoint.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

[tirumal reddy]

On Wed, 22 Jan 2020 at 22:55, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> >> It will be easier for vendors to avoid interposing themselves on
> >> communications that would present legal problems if this extension
> can
> >> clearly say hands-off.
> >>
>
> > I don't get the comment. The decision whether to deploy a TLS proxy
> for the
> > IoT devices/endpoints is up to the organization owning them. The TLS
> proxy
> > has to meet the organization security and privacy requirements.
> Further,
> > middle box administrator configure the firewall to bypass
> > traffic decryption for a connection destined to a specific service
> due to
> > privacy compliance requirements.
>
> In Enterprises that own and control all device that might be true.
> In residential situations where the ISP owns the home router, that's not
> true.
>

Yes, TLS proxy approach will not work in home networks. In addition, I
don't think in near future home routers will be powerful enough to run a
TLS proxy (with the exception of VNF). Alternatively, the middle-box can
probe the server to learn the server certificate.

We will update the draft to clarify the scope of the deployments where
middle-box can act as a TLS proxy.


>
> >> > Middle boxes from several security vendors acting as TLS proxies
> do
> >> > keep up with the updates to protocols
> >>
> >> Well, it's never the good actors that cause the problem.
> >> It's the bad ones :-)
> >>
>
> > I don't think organizations who care about security and privacy, and
> most
> > importantly their reputation and business will deploy such bad TLS
> proxies.
>
> But, those bad ones meant that TLS 1.3 had to adapt to them, rather than
> the
> other way around.
>

The bad ones will continue to be non-compliant, see
https://tools.ietf.org/html/rfc8446#section-9.3


>
> >> The problem here is that the EST mechanism as envisioned by BRSKI
> is not
> >> intended to be a general trust anchor, but rather to validate items
> that
> >> are
> >> within the same domain.
>
> mcr> I just don't think that this is a good way to introduce alternate
> mcr> trust roots.  My recommendation is that you go ahead with the MUD
> mcr> profile that describes TLS profiles, without tying that to TLS
> proxy mechanisms.
>
> > Got it, thanks; updated draft to say the mechanism to configure the
> IoT
> > device with the middlebox's CA certificate is out of scope.
>
> mcr> The malware will include it's own non-public trust-anchor.
>
> > If malware uses it's own non-public trust-anchor, it will be
> detected by
> > the TLS profile (acceptlist-ta-certs and SPKI-pin-sets) and the
> > malware flow will be blocked.
>
> I'm trying to say that the same process is a reasonable way for the device
> to
> call home for firmware updates.   So I suggest that since we have MUD
> ACLs, even for devices which might have relative broad connectivity, we
> should be able to declare a TLS profile (or anchor profile) for specific
> destinations.
>

Good point, will update draft.

Cheers,
-Tiru


>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

[tirumal reddy]

Hi Michael,

Please see inline

On Wed, 22 Jan 2020 at 07:05, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> > No, the proposed mechanism will help identify the presence of
> > unauthorized software or malware on an IoT device.
>
> I understand that there is a lot of prior art and industry experience doing
> this.  A lot of people are quite upset about how these things have
> progressed, but it is not my purpose to tell people how they can or can't
> run
> their network.  It's not my point to argue here.
>
> I am actually in favour of end-to-end authentication and hop-by-hop
> encryption, permitting controlled and clearly authorized auditing.
>

Glad to see we are in the same page :)


> I even wrote draft on this topic in 1996 (for IPsec)
>
> mcr> 2) it seems that manufacturers might be able to say, "HANDS OFF"
> mcr> to IDS systems. (perhaps avoiding use of more colourful language)
>
> > Network security vendors offering firewalls/IPS to enterprise
> networks
> > already have the capability of performing
> > TLS handshake inspection and acting as a TLS proxy, they can leverage
> > the proposed mechanism.
>
> It will be easier for vendors to avoid interposing themselves on
> communications that would present legal problems if this extension can
> clearly say hands-off.
>

I don't get the comment. The decision whether to deploy a TLS proxy for the
IoT devices/endpoints is up to the organization owning them. The TLS proxy
has to meet the organization security and privacy requirements. Further,
middle box administrator configure the firewall to bypass
traffic decryption for a connection destined to a specific service due to
privacy compliance requirements.

Malware identified last year is using DoH to hide the DNS messages from
passive monitoring (see (
https://www.bleepingcomputer.com/news/security/psixbot-modular-malware-gets-new-sextortion-google-doh-upgrades/
)
and such malware communication cannot be detected by DNS based filtering,
malware agents will not use the DoH/DoT server provided by local network,
TLS profile parameters can be used to detect malware communication with C
server for IoT devices with broad communication patterns.

As you may already know, Windows recently had a vulnerability in the
certificate validation function and would accept spoofed certificates
certificates (you can image the problems with IoT devices). Samsung fridge (
https://www.theregister.co.uk/2015/08/24/smart_fridge_security_fubar/)
accepted spoofed certificates because it failed to validate the server
certificate (imagine the problems with off-the IoT devices, see
https://tools.ietf.org/html/draft-arkko-farrell-arch-model-t-01#section-2.3.1.9
).


>
> > Middle boxes from several security vendors acting as TLS proxies do
> > keep up with the updates to protocols
>
> Well, it's never the good actors that cause the problem.
> It's the bad ones :-)
>

I don't think organizations who care about security and privacy, and most
importantly their reputation and business will deploy such bad TLS proxies.


>
> > In any case, it's not BRSKI that matters, but EST(RFC7030)'s
> /cacerts.
> > I see that it's probably difficult to get to RFC7030 just to run
> /cacerts,
> > but if BRSKI is being used already. {If this gets better IoT
> onboarding into
> > Enterprises well. What a Faustian bargin...}
>
> > I believe that attempting to auto-configure a TLS 1.3 MITM proxy
> using EST is
> > a really bad idea. Devices that are willing to fall prey to such a
>
> The problem here is that the EST mechanism as envisioned by BRSKI is not
> intended to be a general trust anchor, but rather to validate items that
> are
> within the same domain.

I just don't think that this is a good way to introduce alternate trust

roots.  My recommendation is that you go ahead with the MUD profile that
> describes TLS profiles, without tying that to TLS proxy mechanisms.
>

Got it, thanks; updated draft to say the mechanism to configure the IoT
device with the middlebox's CA certificate is out of scope.


>
> mcr> Additional, it is entirely reasonable (perhaps, given MITM
> attacks!) for an IoT
> mcr> device manufacturer to "call home" using a baked in, non-public,
> trust
> mcr> anchor. Such a situation would be indiguishable from malware
> calling C
> mcr> using a baked-in trust anchor.
> mcr> I would certainly want to do this for firmware updates.
>
> > I don't get your comment. How will malware's command and control
> server
> > certificate be signed by the baked-in
> > non-public trust anchor on the IoT device ?
>
> The malware will include 

Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

[tirumal reddy]

Hi Michael,

Thanks for the review. Please see inline

On Sat, 18 Jan 2020 at 07:57, Michael Richardson 
wrote:

>
> tirumal reddy  wrote:
> > This revision
> > https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02 updates
> the
> > draft to discuss privacy enhancing technologies and evasion
> techniques
> > used by malware, visibility into TLS 1.3 parameters and how certain
> > types of malware can be blocked without acting as a (D)TLS 1.3 proxy.
>
> > As a reminder, this draft extends Manufacturer Usage Description
> (MUD)
> > to incorporate (D)TLS profile parameters. This allows a network
> > element to identify unexpected (D)TLS usage, which can indicate the
> > presence of unauthorized software or malware on an endpoint.
>
> I have read opsawg-mud-tls, and I am in general very very reluctant to
> provide detailed instructions on doing innovation kill intrusive DPI.
> I think that it will ultimately not result in any improvements to network
> security.
>

No, the proposed mechanism will help identify the presence of unauthorized
software or malware on an IoT device.
MUD is not suitable for IoT devices with broad communication patterns and TLS
profile parameters can be used on such devices to permit intended TLS use
and block malicious TLS use.

Middleboxes act as TLS proxies in several deployments and the behavior of a
compliant TLS 1.3 proxy is discussed in Section 9.3 of
https://tools.ietf.org/html/rfc8446. Most importantly, network security
services have been using TLS profile parameters to successfully identify
malware and benign flows for several years (for example, see
https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/enterprise-network-security/nb-09-encrytd-traf-anlytcs-wp-cte-en.pdf
).

We have profiled several IoT devices in our lab and also observed TLS
profile parameters of thousands of malware flows. Our analysis helped
conclude intended TLS use can be permitted and malicious TLS can be blocked
(see
https://datatracker.ietf.org/meeting/106/materials/slides-106-opsawg-draft-reddy-opsawg-mud-tls
(slides
7 to 15) for more details).


> I see two advantages of this work, which mitigates my concern slightly.
> (but, only slightly)
>1) if it's gonna get done by IDS vendors, then IoT device manufacturers
>   might as well provide a way to help them *get it right*
>2) it seems that manufacturers might be able to say, "HANDS OFF"
>   to IDS systems. (perhaps avoiding use of more colourful language)
>

Network security vendors offering firewalls/IPS to enterprise networks
already have the capability of performing TLS handshake inspection and
acting as a TLS proxy, they can leverage the proposed mechanism. Further,
firewalls acting as TLS proxy do several checks to identify MiTM attack.
For example, the most recent one is the Microsoft vulnerability to validate
certificates
https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF;
middle boxes can identify such MiTM attacks and protect endpoints.


>
> The document says:
>In other words, malware developers will
>have to develop malicious agents per IoT device type, manufacturer
>and model, infect the device with the tailored malware agent and will
>have keep up with updates to the device's (D)TLS profile parameters
>over time.  Further, the malware's command and control server
>certificates need to be signed by the same certifying authorities
>trusted by the IoT devices.  Typically, IoT devices have an
>infrastructure that supports a rapid deployment of updates, and
>malware agents will have a near-impossible task of similarly
>deploying updates and continuing to mimic the TLS behavior of the IoT
>device it has infected.
>
> It seems to me that malware will know exactly, thanks to this extension how
> to perfectly impersonate the device.


Network security services have been using TLS profile parameters to
successfully identify malware and benign flows for several years. The data
features and ML models used by the security services is a public domain
information and also known to malware developers for a long time (for
example see https://arxiv.org/pdf/1607.01639.pdf).


> Given that TLS1.3 makes so many of the
> characteristics of the implementation less visible, it seems that this is
> just a dangerous arms race.  As border MUD gateways get more detailed in
> the
> way they examine things, the ability to innovate in TLS will simply
> diminish.
> It is my understand that we already had to do the TLS 1.3 version
> negotiation
> differently thanks to middle boxes because of such nonsense.
>

Middle boxes from several security vendors acting as TLS proxies do keep up
with the updates to proto

Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

[tirumal reddy]

Hi all,


This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02
updates the draft to discuss privacy enhancing technologies and evasion
techniques used by malware, visibility into TLS 1.3 parameters and how
certain types of malware can be blocked without acting as a (D)TLS 1.3
proxy.



As a reminder, this draft extends Manufacturer Usage Description (MUD) to
incorporate (D)TLS profile parameters.  This allows a network element to
identify unexpected (D)TLS usage, which can indicate the presence of
unauthorized software or malware on an endpoint.



Comments and suggestions are more than welcome.



Cheers,

-Tiru

On Thu, 16 Jan 2020 at 18:58, tirumal reddy  wrote:

>
>
> -- Forwarded message -
> From: 
> Date: Thu, 16 Jan 2020 at 18:44
> Subject: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt
> To: Tirumaleswar Reddy.K , Dan Wing ,
> Blake Anderson 
>
>
>
> A new version of I-D, draft-reddy-opsawg-mud-tls-02.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-opsawg-mud-tls
> Revision:   02
> Title:  MUD (D)TLS profiles for IoT devices
> Document date:  2020-01-16
> Group:  Individual Submission
> Pages:  19
> URL:
> https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
> Htmlized:   https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-02
>
> Abstract:
>This memo extends Manufacturer Usage Description (MUD) to incorporate
>(D)TLS profile parameters.  This allows a network element to identify
>unexpected (D)TLS usage, which can indicate the presence of
>unauthorized software or malware on an endpoint.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

[tirumal reddy]

-- Forwarded message -
From: 
Date: Thu, 16 Jan 2020 at 18:44
Subject: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt
To: Tirumaleswar Reddy.K , Dan Wing ,
Blake Anderson 



A new version of I-D, draft-reddy-opsawg-mud-tls-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-opsawg-mud-tls
Revision:   02
Title:  MUD (D)TLS profiles for IoT devices
Document date:  2020-01-16
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-02.txt
Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:   https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-02

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to incorporate
   (D)TLS profile parameters.  This allows a network element to identify
   unexpected (D)TLS usage, which can indicate the presence of
   unauthorized software or malware on an endpoint.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt

[tirumal reddy]

Hi all,

This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01
updates the MUD (D)TLS profile to include grease extension, visibility into
TLS 1.3 parameters,  pre-shared key exchange modes and Encrypted SNI.

We observed several IoT devices are already using Grease extension.

Comments and suggestions are more than welcome.

Cheers,
-Tiru

-- Forwarded message -
From: 
Date: Tue, 3 Sep 2019 at 16:13
Subject: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt
To: Tirumaleswar Reddy , Dan Wing 



A new version of I-D, draft-reddy-opsawg-mud-tls-01.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-opsawg-mud-tls
Revision:   01
Title:  MUD (D)TLS profiles for IoT devices
Document date:  2019-09-03
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-01.txt
Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:   https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-01

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to model DTLS
   and TLS usage.  This allows a network element to notice abnormal DTLS
   or TLS usage which has been strong indicator of other software
   running on the endpoint, typically malware.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] The future of MUD work

[tirumal reddy]

A new WG to focus on MUD sounds like a good idea. Several vendors and ISPs
offer security services to protect home networks, protecting IoT devices in
home networks is one of the key challenges, and MUD can help secure IoT
devices in both Enterprise and home networks and the security solutions in
both these networks are quite different.

Cheers,
-Tiru

On Wed, 31 Jul 2019 at 14:15, Eliot Lear  wrote:

> On the other hand, it shouldn’t just be me.  It’d be a very small working
> group ;-) If others are interested, they should speak up.
>
> On 30 Jul 2019, at 11:09, Eliot Lear  wrote:
>
> Signed PGP part
> Hi Joe,
>
> On 29 Jul 2019, at 23:44, Joe Clarke (jclarke)  wrote:
>
> OpsAWG members and our Ops ADs, it was discussed in opsawg at IETF 105
> that with the amount of MUD work being proposed (and discussions happening
> outside of opsawg) that perhaps MUD should evolve into its own WG.  Some
> cons to this approached were discussed (maybe it would be too heavy-weight
> with a charter, milestones, etc.).  However, I wanted to take this
> conversation to the list so we can close on it publicly.
>
> Speaking as WG co-chair, I am happy to continue to support the MUD work in
> opsawg, but I want to make sure the WG feels compelled to work on it; and I
> want to make sure the full community that is interested in MUD can follow
> and discuss items here.  That said, it was mentioned in 105 that perhaps a
> bigger “on-boarding” set of work would be better served in its own WG.  I
> think if the scope of MUD grows beyond the definition and its extensions
> (as we’ve been seeing the work progress thus far) it might be better served
> in its own WG space.
>
> Thoughts?
>
>
> I think it is probably time for at least one WG to spring from OPSAWG.  We
> didn’t really complete the agenda at the IETF, and a good reason of that
> was MUD.  There are at least four active drafts on that one subject, one of
> which we didn’t really talk about (bw-profile).  For me it’s a matter of
> what can reasonably be coded, tested, and be useful for manufacturers.  In
> as much as we can bring a bit more focus to manufacturers by offering them
> more of a venue for discussion, the additional WG would be welcome.  On the
> other hand, if we find that we’re not making progress, or if we progress
> extensions quickly, we can close the WG and continue the mailing list, and
> move back to OPSAWG.  I don’t see a MUD working group as a long term
> activity (famous last words), but targeted more at producing the necessary
> for broader adoption and then going out of business.
>
> Eliot
>
>
> Joe
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Fwd: New Version Notification for draft-reddy-opswg-mud-tls-00.txt

[tirumal reddy]

Hi Qin,

Please see inline

On Tue, 9 Jul 2019 at 08:30, Qin Wu  wrote:

> Interesting work, three questions:
>
> 1.   Can the IoT device (D)TLS profile be disclosed to malicious agent or 
> IoT device? If not, how do you prevent these sensitive information leaking?
>
> It is not sensitive information, on-path network devices can inspect or
monitor the TLS handshake without acting as a TLS proxy. In TLS
1.3, ClientHello message is not encrypted and few parameters in the
ServerHello message are still visible (such as the chosen cipher).


> 2.   Do you frequently update DTLS profile disclosed to IoT device to 
> prevent malicious agent from snooping?
>
> No, Malware frequently uses its own libraries (SSL config) for its
activities, and malware developers will have to develop malicious agents
per IoT device type, manufacturer and model (which will be several
thousands and practically not possible).

> 3.   How does enterprise firewal use DTLS profile to detect malicious 
> flow or legitimate flow?
>
> If (D)TLS session from the IoT device violates MUD (D)TLS profile,
firewall detects the flow is malicious and blocks it. As you may know,
Enterprise firewalls inspect TLS handshake and are capable of acting as a
(D)TLS proxy (please see
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-05).

Cheers,
-Tiru

-Qin
>
> *发件人:* OPSAWG [mailto:opsawg-boun...@ietf.org] *代表 *tirumal reddy
> *发送时间:* 2019年7月8日 22:03
> *收件人:* opsawg@ietf.org; m...@ietf.org
> *主题:* [OPSAWG] Fwd: New Version Notification for
> draft-reddy-opswg-mud-tls-00.txt
>
>
>
> This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> discusses Manufacturer Usage Description (MUD) extension to model (D)TLS
> profile on IoT devices. This allows a firewall to notice abnormal DTLS or
> TLS usage, which has been a strong indicator of other software running on
> the endpoint, typically malware.
>
>
> Comments, suggestions, and questions are more than welcome.
>
> Cheers,
> -Tiru
>
>
>
> -- Forwarded message -
> From: 
> Date: Mon, 8 Jul 2019 at 19:18
> Subject: New Version Notification for draft-reddy-opswg-mud-tls-00.txt
> To: Tirumaleswar Reddy , Dan Wing 
>
>
>
>
> A new version of I-D, draft-reddy-opswg-mud-tls-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-opswg-mud-tls
> Revision:   00
> Title:  MUD (D)TLS profiles for IoT devices
> Document date:  2019-07-08
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
> Htmlized:   https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls
>
>
> Abstract:
>This memo extends Manufacturer Usage Description (MUD) to model DTLS
>and TLS usage.  This allows a network element to notice abnormal DTLS
>or TLS usage which has been strong indicator of other software
>running on the endpoint, typically malware.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] New Version Notification for draft-reddy-opswg-mud-tls-00.txt

[tirumal reddy]

Thanks Eliot, glad to present the draft.

-Tiru

On Mon, 8 Jul 2019 at 20:02, Eliot Lear  wrote:

> I think this is a pretty cool idea.  You should talk about it if you can
> make the side meeting, or otherwise if you can get time at opsawg.
>
> Eliot
>
> On 8 Jul 2019, at 16:03, tirumal reddy  wrote:
>
> This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> discusses Manufacturer Usage Description (MUD) extension to model (D)TLS
> profile on IoT devices. This allows a firewall to notice abnormal DTLS or
> TLS usage, which has been a strong indicator of other software running on
> the endpoint, typically malware.
>
> Comments, suggestions, and questions are more than welcome.
>
> Cheers,
> -Tiru
>
> -- Forwarded message -
> From: 
> Date: Mon, 8 Jul 2019 at 19:18
> Subject: New Version Notification for draft-reddy-opswg-mud-tls-00.txt
> To: Tirumaleswar Reddy , Dan Wing 
>
>
>
> A new version of I-D, draft-reddy-opswg-mud-tls-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-opswg-mud-tls
> Revision:   00
> Title:  MUD (D)TLS profiles for IoT devices
> Document date:  2019-07-08
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
> Htmlized:   https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls
>
>
> Abstract:
>This memo extends Manufacturer Usage Description (MUD) to model DTLS
>and TLS usage.  This allows a network element to notice abnormal DTLS
>or TLS usage which has been strong indicator of other software
>running on the endpoint, typically malware.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> --
> Mud mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mud
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Fwd: New Version Notification for draft-reddy-opswg-mud-tls-00.txt

[tirumal reddy]

This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
discusses Manufacturer Usage Description (MUD) extension to model (D)TLS
profile on IoT devices. This allows a firewall to notice abnormal DTLS or
TLS usage, which has been a strong indicator of other software running on
the endpoint, typically malware.


Comments, suggestions, and questions are more than welcome.

Cheers,
-Tiru


-- Forwarded message -
From: 
Date: Mon, 8 Jul 2019 at 19:18
Subject: New Version Notification for draft-reddy-opswg-mud-tls-00.txt
To: Tirumaleswar Reddy , Dan Wing 



A new version of I-D, draft-reddy-opswg-mud-tls-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-opswg-mud-tls
Revision:   00
Title:  MUD (D)TLS profiles for IoT devices
Document date:  2019-07-08
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
Status: https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
Htmlized:   https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls


Abstract:
   This memo extends Manufacturer Usage Description (MUD) to model DTLS
   and TLS usage.  This allows a network element to notice abnormal DTLS
   or TLS usage which has been strong indicator of other software
   running on the endpoint, typically malware.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg