From kondtir@gmail.com Mon Jan 22 22:20:56 2024 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5245C14F75F for ; Mon, 22 Jan 2024 22:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVK7CRKZcPIr for ; Mon, 22 Jan 2024 22:20:52 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D09CC14F6F0 for ; Mon, 22 Jan 2024 22:20:52 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a3081516dd7so36555766b.1 for ; Mon, 22 Jan 2024 22:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705990850; x=1706595650; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YUTl4EDF3gkDaA2FI78W8Rc8gkLAYazO/+tk8YY9Gvs=; b=Ahx1tXCaJjLpVMJHL4/Qlc5ZsHfbnBFEOvkvYj7Jb7Vv3voN4V5E+yI+LWqr/ZzzzI 6DRZmJPPQj05Qx5wpZLJoB1FtzRplQMN0k0u4I6lB1unzmNB8V0zXvTQrCopluWLDAzd P64YV8ZeDUJyUWGPS2gu1BJx/KzZoPDCUv/xIf8oMj3QRf0xFH2ZaspBNKatlPnXWN9F R6hWaVheplt6DvIrLP/8dxGmUTdy5jIdqsFjDEi0u326c9A3Uqg/LLbMs/lDKM5d+te5 xpOWC+X8HqGWwffwWhmOAWYAs+rAsIII8yCOkBatdkqulcWgG/Twkl4fO0T2HONfcMxl cUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705990850; x=1706595650; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YUTl4EDF3gkDaA2FI78W8Rc8gkLAYazO/+tk8YY9Gvs=; b=ORi00q+WM6ehW0mUqaomMV1ry45Y6rMtIUcVDExkzoeqCTVqZlMt44W6yjTe1KZsVw BaYYmcXJLIWL4eXFKnyPcnDlYFbnrNNDXkELP0eMqD62igA60PdPdl/AsZns5K4oeXNc x6CbNIIG76N4uatKnpTdQ03mBv1z0dFbceOjgZNnrIDK1llvnEttOJSMTPHSkeztPpaQ xhKXondwb4ICi1s7V+6THG4WbEVfWJErxLx9MJrKZyxVOdZbrpxY9IyIa69mVCqCZ7ZU nBeDRM7spTVZRVefo+yTQlg3KHIJCDzjuKnOE4WNt++CzMxq64/Ro59L9sKJySaLJiS0 LalQ== X-Gm-Message-State: AOJu0YxNMZ+RW992iCceu8ciFm0+IGmUyX+m4TlmOjqOZsHm6DQahjNz W3+lToVe2HiBFFFbeWSV0cLF5eSmxvFGrntXl2Wsgl0OXGK6BTQn3tjIHAE4+AstAb2FbFh8Jvz srbTTf8aVL1b0uOJkuXsl8+P1ntY= X-Google-Smtp-Source: AGHT+IE7u/wKDD+iPnTr7Xwczki4cmVXQoTtD3o7MT3SJpVQaWLv+OVRc7JfdcScKG1Ys4OhWCdO+Q/WQeFf6LugRxw= X-Received: by 2002:a17:906:f84a:b0:a30:d080:93 with SMTP id ks10-20020a170906f84a00b00a30d0800093mr217493ejb.6.1705990850058; Mon, 22 Jan 2024 22:20:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: tirumal reddy Date: Tue, 23 Jan 2024 11:50:13 +0530 Message-ID: To: Paul Wouters Cc: danwing@gmail.com, blake.anderson@cisco.com, opsawg@ietf.org Content-Type: multipart/alternative; boundary="0000000000009b9e5a060f96f2f2" Archived-At: Subject: Re: [OPSAWG] AD review draft-ietf-opsawg-mud-tls-12 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2024 06:20:56 -0000 --0000000000009b9e5a060f96f2f2 Content-Type: text/plain; charset="UTF-8" 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&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 cipher ianatp: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 > > --0000000000009b9e5a060f96f2f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for the revi= ew. Please see inline=C2=A0

On Sat, 20 Jan 2024 at 03:55, Paul Wouters <<= a href=3D"mailto:paul.wouters@aiven.io">paul.wouters@aiven.io> wrote= :
Hi,

I am assisting Rob Wilton with some do= cuments, as so I am the (temporary) responsible AD for draft-ietf-opsawg-mu= d-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 h= ostnames. I don't have as much faith in using MUD to identify rogue TLS= connections based on their cryptographic or extension properties (eg ciphe= rsuites). I would expect that ciphersuites would change, and that an IoT de= vice would mostly only implement the one or two ciphersuites (and TLS exten= sions) it supports. Malware would have to ensure their C&C can talk all= kinds of ciphersuites and extensions to allow all kinds of limited impleme= ntation IoT devices to connect to it. So I don't think those parts woul= d likely to trigger a MUD security rule. But there is no harm in trying.

In our research, TLS properties c= an be used to identify benign and malware flows. The results with Google Ho= me and several malware families were presented in T2TRG few years back, ple= ase see=C2=A0https://datatracker.ietf.org/meeting/interim-2020-t2trg= -01/materials/slides-interim-2020-t2trg-01-sessa-mud-dtls-profiles-for-iot-= devices-00.pdf=C2=A0for details.=C2=A0
=C2=A0

Some specific questions:

=C2=A0=C2=A0 +--rw supp= orted-tls-version* =C2=A0 =C2=A0 =C2=A0 =C2=A0ianatp:tls-version
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw supported-dtls-version* =C2=A0 =C2=A0 =C2= =A0 ianatp:dtls-version
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw cipher-= suite* [cipher hash]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw ci= pher =C2=A0 =C2=A0ianatp:cipher-algorithm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0+--rw hash =C2=A0 =C2=A0 =C2=A0ianatp:hash-algorithm
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw extension-type*
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 ianatp:extension-type
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw accept-list-ta-cert*
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 ct:trust-anchor-cert-cms
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw psk-key-exchange-mode*
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 ianatp:psk-key-exchange-mode=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 {tls13 or dtls13= }?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw supported-groups*
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 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 t= he
DH part in the ciphersuite. How would those be expressed? I
know t= he 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 expr= ess 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
abou= t DH groups?)

Good catch, m= odified the YANG module to use uint16 to represent the cipher suite to=C2= =A0match the TLS IANA registry of cipher suite (that includes non-AEAD ciph= ers). The supported-group in the YANG module matches TLS supported groups r= egistry, see https://www.iana.org/assignments/tls-pa= rameters/tls-parameters.xhtml#tls-parameters-8.=C2=A0
=C2=A0<= /div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw application-protocol*
Is ALPN meant here?

Yes, plea= se see Section 5.3 of the draft

=C2=A0 typedef app= lication-protocol {
=C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 descript= ion
=C2=A0 =C2=A0 =C2=A0 "Application-Layer Protocol Negotiation (A= LPN) Protocol ID
=C2=A0 =C2=A0 =C2=A0 =C2=A0registry as defined in Sect= ion 6 of RFC7301.";
=C2=A0 }
=C2=A0
Perhaps using &= quot;alpn" instead of "application-protocol"
would be cle= arer? But I'm okay with whatever the WG / authors deem better.

S= ection 9:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 An attacker cannot read the MU= D URL and identify the IoT device.

Should this be "so that an a= ttacker ....." ?

It could use a more inclusiv= e term for "man-in-the-middle", eg "on path attacker" o= r "machine-in-the-middle"

=
Agreed, updated text as follows:

=C2=A0 =C2= =A0The MUD URL MUST be encrypted and shared only with the authorized compon= ents in the
=C2=A0 =C2=A0network (see Section 1.5 and Section 1.8 of [RF= C8520]) so that an on-
=C2=A0 =C2=A0path attacker cannot read the MUD UR= L and identify the IoT device.

Cheers,
-Tiru
=C2=A0

Once the above questions are ans= wered and possibly resolved with new text, I think the document is ready fo= r IETF LC.

Paul

--0000000000009b9e5a060f96f2f2--