Hi Ben,
Much of this relitigates RFC 8520, but IMHO it is worth reviewing assumptions
from time to time. Remember, the purpose of MUD is to identify an
authorization profile for a device to a network so that either access can be
granted based on that profile or an anomaly can be detected. The
Hi Nick,
Thanks for the response and I apologize for my delayed response. However I
still have two major concerns regarding the current proposed text:
Mentioning keyless as the only solution complementary to DC still seems to
me technically inaccurate. With KeylessSSL, the key server receives a
I tend to agree with Ben Schwartz on this. I have two
concerns about this draft:
1. It seems likely that it will lead to ossification. While
it is true that devices can in theory update their MUD
descriptions, as a practical matter expecting middleboxes
to enforce certain properties of the TLS han
* So, hiding whether a server supports ECH or not (which I called level 2)
is a significantly higher bar than hiding whether a particular connection is
using ECH or not (level 1).
* I would like to understand how the WG feels about this requirement and
that there is consensus that we ne