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

tirumal reddy <> Tue, 22 September 2020 10:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A7F03A0B75; Tue, 22 Sep 2020 03:34:27 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 U8LLnPt9Soz2; Tue, 22 Sep 2020 03:34:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EACE83A15FA; Tue, 22 Sep 2020 03:34:25 -0700 (PDT)
Received: by with SMTP id l16so3310978ilt.13; Tue, 22 Sep 2020 03:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jOEqEz1MuIukHs9Dlsg3jJBhxvG5eAsgYZ5/PF5wP1w=; b=rg6ixC/zlsofESLW/7oxgZ+MLv2WISsn2iWn4cuWQ7nZ0oeIEJkL/67mqHgybjBWOz Tmzu0iHOEjnEqLjjn12nRRz9BBCtZTFY2fDLTiovV+4BHkrCpaY0QfkbyelJP/rd+3mO RKoFwp+yx5h/XainJb4UImcn5wyQomGo78NkyP36XcHO4mInEvtxhwW6e4YvrCaLhzlR +nljADAFQAiFFIhgqzLxCLEhXHIhax8cZ5qNT/osOIZR1Q3ZXeIAZbn64nOah2SRLONB CQo4vXqNRvkX7WOrzz9qbUxIVgPT0dHqzNHSbyI8IP/m+1gxa0HjlqeKBGEzWveAiDr9 CK8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jOEqEz1MuIukHs9Dlsg3jJBhxvG5eAsgYZ5/PF5wP1w=; b=Rnp1QH9iE9xX6HO/lgzDgXMCW7uRMYcpsLs8ZX4ben7FZFT9QhpLtVWmDRIxOMiS+l H7T/WGjUgQh6jNRMZ2+3/nPHZba3Sfixjp4qmXMbVac3aSifRP28kTkS5qeiy+7j6WBr biHV3vOqu2tpVO35XWyoHg+12LT73b953x5MNPo3fFFtS3z73RIR/fejQftlXhxhe9XG cJwASFC9+/xzU8JuqJOL5ysnb9ZMk2NiQKy4XroZrxKe/+jYSNTAE8rA0RscxOYLyS2i 24kMauLx97WuaKlIQ/QASaoQTOoJn9e6SjgSobGUyoqeHp1YbGDPR2h3J8ECuyR6fhzD 6dpQ==
X-Gm-Message-State: AOAM530RvOkfdPZ2DLLwQ8hzqj+I+YwEAXjZROXD6GmztlBs8mSH/QVQ sLLaityqQr2h9d3bW6SHr4mQSAg6LJZPA8/zdeY=
X-Google-Smtp-Source: ABdhPJz6Brn1OjNLB7W1miceS+1M54y1El6EMltLg13nz5kuIcQUlxFmejtdhM3c0RsdXaRg8uusBw5Q3NMMviXLfgc=
X-Received: by 2002:a92:b306:: with SMTP id p6mr3610473ilh.195.1600770865198; Tue, 22 Sep 2020 03:34:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Tue, 22 Sep 2020 16:04:13 +0530
Message-ID: <>
To: Nick Harper <>
Cc: Watson Ladd <>, Eliot Lear <>, opsawg <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000c9804b05afe48232"
Archived-At: <>
Subject: Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Sep 2020 10:34:27 -0000

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