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

Hi Nick,

Please see inline

On Wed, 16 Sep 2020 at 06:00, Nick Harper <nharper@google.com> 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 <watsonbladd@gmail.com> wrote:
>
>> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
>> <lear=40cisco.com@dmarc.ietf.org> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>