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

Dan Wing <> Wed, 16 September 2020 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 383C83A10D4; Wed, 16 Sep 2020 13:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bM2ifkPqM9Ki; Wed, 16 Sep 2020 13:48:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41C6C3A10E1; Wed, 16 Sep 2020 13:48:41 -0700 (PDT)
Received: by with SMTP id d9so4696977pfd.3; Wed, 16 Sep 2020 13:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=itd3dFv1Ku5OYKTll9eAT8TUVvUmQJvKM+T6qUnHhmU=; b=K0YDT5lhfvpNBf17+S59GB4mpRZMTFCIJLrpXuyhLbQmdWbuaJdHk5EoP8E8NOAxiN 3vV91GIkXNiv+yoa2f817ropwu9u7NPOwnsJmHZj9BA93iir5xTC9HEiXsPZZ5g8pqKm QWhwzUHKutfA8+MTv89DbllXkt1ax7HPVntCsKMSnrP7VCOLCIvG8obYrSAVhjUwtvwf fjx7i7mvylbP19MDCDfBmzA2i8RH47tKxBl8ubKVhu3TQLEGFSMZUJ1/w1JpkGSSz+tR nx3AVlPzK7EkrToLXbKDmtvFA7nP/JmxAHwE+9UFB6A/Sv9432sZ/bNd1l07DTyHcB+p YxLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=itd3dFv1Ku5OYKTll9eAT8TUVvUmQJvKM+T6qUnHhmU=; b=VItZBFIuA+1ehFSVVuSgCOppB7EvVyCotxljzDWwHfCpQbMTrDEY28Hj9BXLz5qOg0 TRycAAzobSpq1OEm0yei5PQ+Lg4ravLDOdxX3nVx1KX/gmOAub59PtXec0ZxLibMlPJ7 MOYC3e79cFXl32VaAINULoJbllAFL4ogLIs3j5EjeYoidwduVSGyhhVfXzF+uRtjFiKC yhyf1dHW8R1GxKc/om2pdUd+js4S8DC2ixI12RaI+cSaTMeZMSZUjHWWGox1mSmMoKKa HH31bWhgW0hiGUl4PZvmE/+AboYJ7fBuSJjkS7vCzyDp3o8wTSR0P5mzJfyxwqDC1lda Jfnw==
X-Gm-Message-State: AOAM532xuh/XH4KaCSo+jv3xaRfT5YTXwv70P6petca07JeYvmT3x+ZM RVrE4FfTutv8h0436vmbaXc=
X-Google-Smtp-Source: ABdhPJwH8v7Tr2kRI39BZ/LqI5mhLxFNNPu0qTp4ExHe4HTfcjJa+ddn2pkLtds0FMwp5fqj8MXzRw==
X-Received: by 2002:a63:4822:: with SMTP id v34mr19515407pga.342.1600289320745; Wed, 16 Sep 2020 13:48:40 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id d15sm10087992pfo.85.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2020 13:48:40 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Dan Wing <>
In-Reply-To: <>
Date: Wed, 16 Sep 2020 13:48:38 -0700
Cc: Tirumaleswar Reddy <>, Watson Ladd <>, opsawg <>, Eliot Lear <>, "<>" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Nick Harper <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Sep 2020 20:48:42 -0000

On Sep 16, 2020, at 1:08 PM, 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.

Yes, that is the better way to handle GREASE:  expect Grease from any client, on any TLS value (as Ben pointed out supported_versions may well be Grease'd next).