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

[Eric Rescorla]

On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy  wrote:

> Hi Ben,
>
> Please see inline
>
> On Tue, 22 Sep 2020 at 20:45, Ben Schwartz  wrote:
>
>> I'm not able to understand the new text in Section 6.  Are you saying
>> that clients MUST include all the listed extensions/features, but MAY also
>> include extensions/features not listed in the MUD profile?  So the MUD
>> profile only acts as a "minimum" set of features?
>>
>
> Section 6 discusses the firewall behaviour when it sees a) known
> extensions/features in a TLS session but not specified in the MUD profile
> b) unknown extensions/features in a TLS session either specified or not
> specified in the MUD profile c) updated MUD profile specifying
> extensions/features  not supported by the firewall.
>
> If the client supports new features/extensions but not yet added in the
> YANG module, it can be updated using expert review or specification
> required registration procedure, discussed in
> https://tools.ietf.org/html/rfc8126.
>

I think this misunderstands the point.

Suppose I want to add feature X. There are (at least) two scenarios:

1. Add a new feature and it just works.
2. I have to get it added to the YANG module, then get middlebox vendors to
change their software which may involve introducing some new parser for
that feature, then I can publish a policy, and it works.

Option (2) is going to take much longer to happen than option (1).
Depending on how slow the vendors are, it could be indefinitely long. Given
that it's often not viable to roll out new networking features if they
introduce any significantly increased risk of failure, this seems like a
recipe for ossification.

-Ekr


> Cheers,
> -Tiru
>
>
>>
>> On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy  wrote:
>>
>>> On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:
>>>


 > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
 >
 > On Fri, 11 Sep 2020 12:32:03 +0530
 > tirumal reddy  wrote:
 >
 >> The MUD URL is encrypted and shared only with the authorized
 >> components in the network. An  attacker cannot read the MUD URL and
 >> identify the IoT device. Otherwise, it provides the attacker with
 >> guidance on what vulnerabilities may be present on the IoT device.
 >
 > RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
 > over LLDP without - so far as I was able to see - any mechanism by
 which
 > it should be meaningfully "encrypted" as to prevent an attacker on
 your
 > network from reading it.

 That’s a bit of an overstatement.  RFC 8520 specifies a component
 architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/
 certificate).  Two other mechanisms have already been developed (QR code,
 Device Provisioning Protocol), and a 3rd new method is on the way for
 cellular devices.

 I would not universally claim that a MUD URL is secret but neither
 would I claim it is not.  The management tooling will know which is which,
 as will the manufacturer, and can make decisions accordingly.

 This having been said, it seems to me we are off on the wrong foot
 here.  The serious argument that needs to be addressed is Ben’s and EKR's.
 We have to be careful about ossification.

>>>
>>> In order to address the comments on ossification, we added a new section
>>> 6 to explain the rules to processing the MUD (D)TLS rules to handle unknown
>>> TLS parameters and updated Section 10 to enable faster update to the YANG
>>> module. Please see
>>> https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt
>>>
>>> -Tiru
>>> ___
>>> TLS mailing list
>>> t...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

On Sat, Sep 19, 2020 at 3:07 PM Michael Richardson 
wrote:

>
> Eric Rescorla  wrote:
> ekr> As a thought example, consider a hypothetical TLS 1.4 which
> decided to
> ekr> adopt QUIC-style obfuscation of the CH and SH, putting the
> obfuscated
> ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system
> described
> ekr> here would be unable to do anything useful with that, which
> creates
> ekr> pressure to block TLS 1.4 entirely, which obviously is not
> awesome.
> >>
> >> I believe that without a mechanism described in this document, many
> >> enterprises may conclude that they need to block TLS 1.3.
> >>
>
> > Perhaps you mean some hypothetical TLS 1.4?
>
> No, I do mean 1.3.   Many enterprises still think that they can stop it.
> Are they winning? probably not.
>

Can you say more about this? While during previous transitions clients
would "fall back" to lower versions of TLS, both Chrome and Firefox (and I
imagine Edge and Safari but I have less information) do not do so. As a
result any middlebox which blocks 1.3 will effectively cause failures on
any site which offers 1.3, which seems like it would cause a lot of
problems.


> >> The idea of having a WASM file is an
> >> interesting one, but being an executable of a sort, it has other
> security
> >> problems.
>
> > Well, one always has to worry about the security of processing data
> one
> > receives from the network, but I'm not sure that the distinction
> between
> > the kind of DSL we're talking about here and an executable is really
> that
> > sharp. The argument for WASM or something like it is that there has
>
> Such as DSL would have to limit the number of cycles it is allowed to
> consume, otherwise the middle box might have to solve the halting problem
> :-)
> BPF could be another model.
>

Agreed. I know BPF less well but my understanding is that it has gotten
quite powerful.

-Ekr
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson 
wrote:

>
> ekr> Taking a step back from details, ISTM that the whole design of this
> ekr> document is antithetical to extensibility:
>
> I agree.  It was my first reaction as well.
> I then had another thought: there are dozens of entities out there that
> want
> to do this regardless, enough that it broke the TLS version system
> requiring
> the hack. (Does that hack have a name?)
>

There are actually two things here:

1. Changing the version system -- this was done mostly to accommodate
broken servers.
2. Compatibility mode (hiding the HRR, fake CCS, etc.) -- this was designed
to work around
broken middleboxes.


We can call them stupid, or we can try to understand their point of view,
> and
> try to help them be less stupid.
>

I don't believe that my note calls them stupid.

In any case, ISTM that the design principle that both 1.3 and QUIC have
converged on is
to opaque-ify as much of the handshake as possible, thus discouraging
passive protocol
enforcement of this kind.



ekr> TLS is a protocol with a number of extension points. What this document
> ekr> does is allow an endpoint to restrict its use of a certain set of
> ekr> extension points. However, the language provided here is
> insufficiently
> ekr> rich to allow the client to properly describe the use of those
> ekr> points.
>
> assuming that some language could be provided that was sufficiently rich,
> would your objection continue to stand?
>

I think it's quite likely that that language would have to be
Turing-complete. I note that
the current language is already very complicated and yet insufficiently
rich.


> ekr> As a concrete example: for extensions the model knows about
> ekr> (e.g., supported_versions) you can indicate the contents of the
> ekr> extension, but for extensions the model does not know about (e.g.,
> ECH)
> ekr> you cannot. That means that you're either stuck with allowing anything
> ekr> in those extensions (which means that your filtering effectiveness is
> ekr> reduced) or you don't allow those extensions, in which case you
> create ossification.
>
> ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to
> ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated
> ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described
> ekr> here would be unable to do anything useful with that, which creates
> ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome.
>
> I believe that without a mechanism described in this document, many
> enterprises may conclude that they need to block TLS 1.3.
>

Perhaps you mean some hypothetical TLS 1.4?

There is already very widespread deployment of TLS 1.3 for HTTPS and
blocking it would cause breakage of a large number of sites. Perhaps you
could safely do it for non-443 ports...



> ekr> If we want to pursue this kind of idea -- and I'm not at all sure we
> ekr> should -- ISTM that rather than trying to invent some new DSL for
> ekr> filtering TLS we allow the client (who by hypothesis is trusted as to
> ekr> what it will generate) to provide a general program that the middlebox
> ekr> can interpret that will describe what it will do. For instance, you
> ekr> could provide a WASM file which gets fed the CH and just says "this is
> ekr> me" or "this doesn't look like me". That way we don't need to continue
> ekr> extending the language here whenever TLS evolves. Note that that
> doesn't
> ekr> prohibit having a language like this as a programming convenience, but
> ekr> it wouldn't restrict the semantics of what you could say about the
> ekr> connection.
>
> We don't have to have the client provide it, it can be encoded by the
> manufacturer in the MUD file, assuming that it depends upon the model, not
> some local decision in the client.


Sorry, yes. I meant "client" in the sense that the client tells the
middlebox what rules to use. Whether it does so directly or by reference to
the manufacturer doesn't seem to matter too much for these purposes.



> The idea of having a WASM file is an
> interesting one, but being an executable of a sort, it has other security
> problems.
>

Well, one always has to worry about the security of processing data one
receives from the network, but I'm not sure that the distinction between
the kind of DSL we're talking about here and an executable is really that
sharp. The argument for WASM or something like it is that there has already
been enormous investment in building sandboxed interpreters for it, so one
gets to inherit all of that effort. This is not, of course, to say that the
WASM sandbox will never have vulnerabilities,but one can generally not say
that about any software.

-Ekr
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

Taking a step back from details, ISTM that the whole design of this
document is antithetical to extensibility:
TLS is a protocol with a number of extension points. What this document
does is allow an endpoint to restrict its use of a certain set of extension
points. However, the language provided here is insufficiently rich to allow
the client to properly describe the use of those points. As a concrete
example: for extensions the model knows about (e.g., supported_versions)
you can indicate the contents of the extension, but for extensions the
model does not know about (e.g., ECH) you cannot. That means that you're
either stuck with allowing anything in those extensions (which means that
your filtering effectiveness is reduced) or you don't allow those
extensions, in which case you create ossification.

As a thought example, consider a hypothetical TLS 1.4 which decided to
adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated CH/SH
in extensions in a stereotyped outer CH/SH. The system described here would
be unable to do anything useful with that, which creates pressure to block
TLS 1.4 entirely, which obviously is not awesome.

If we want to pursue this kind of idea -- and I'm not at all sure we should
-- ISTM that rather than trying to invent some new DSL for filtering TLS we
allow the client (who by hypothesis is trusted as to what it will generate)
to provide a general program that the middlebox can interpret that will
describe what it will do. For instance, you could provide a WASM file which
gets fed the CH and just says "this is me" or "this doesn't look like me".
That way we don't need to continue extending the language here whenever TLS
evolves. Note that that doesn't prohibit having a language like this as a
programming convenience, but it wouldn't restrict the semantics of what you
could say about the connection.

-Ekr


On Wed, Sep 16, 2020 at 1:09 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.
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

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 handshake seems
likely to mean that they will not do a good job with
unknown data. For instance, this document specifies ways
to describe:

(1) a list of supported extensions types

(2) the expected contents of certain extensions (e.g.,
named groups)

But what happens when a new extension type is created?
It seems fairly optimistic to think that middleboxes
will just accept whatever stuff the client generates
as long as it's one of the listed code points.



2. This document seems to encourage the use
of terminating (MITM) forward proxies (in Section 4.1).
In the past, the IETF has explicitly avoided endorsing
this practice.

-Ekr








On Thu, Sep 10, 2020 at 6:36 PM Ben Schwartz  wrote:

> Thanks for highlighting this, Michael.  I don't support adoption of this
> draft, because I don't think it is fit-for-purpose.  Specifically, I think
> it is likely to provide a significant advantage to malware authors (the
> opposite of the intended effect).
>
> Currently, if a malware author wants to match the TLS characteristics of
> the host device, they have to do some work to characterize its TLS
> behavior.  This may be difficult, especially in the case of partial
> compromise, or for malware that targets a wide variety of hosts.  However,
> with this MUD module in place, the malware can read the TLS behavior right
> out of the MUD profile, and configure its behavior to match.
>
> Note that, except in the case of TLS termination, the proxy cannot verify
> anything about the TLS session by observing it.  Just because a connection
> appears to use a particular SNI or certificate does not prove anything
> about the actual destination.
>
> On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson 
> wrote:
>
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
>> > Hello, opsawg.  This draft as underwent a number of revisions based on
>> reviews and presentations at the last few IETF meetings.  The authors feel
>> they have addressed the issues and concerns from the WG in their latest
>> posted -05 revision.  As a reminder, this document describes how to use
>> (D)TLS profile parameters with MUD to expose potential unauthorized
>> software or malware on an endpoint.
>> >
>> > To that end, this serves as a two-week call for adoption for this
>> work.  Please reply with your support and/or comments by September 16, 2020.
>>
>> I have read the document in a number of different revisions, and I
>> support adoption.
>>
>> I have been concerned that this document codifies a kind of TLS snooping
>> by middle boxes which has in the past caused significant harm to
>> development of TLS. (In particular, TLS version negotiation has had to
>> evade existing middle box policies!)
>>
>> However,  this document seems to walk the fine line between causing
>> protocol ossification and providing real security.  To the extent that
>> it reduces the pressure by enterprises to invade the TLS encryption
>> envelope through use of Enterprise certificates [is there a term for the
>> activity describe in section 4.1? I wish there was] this document is a
>> very useful thing.
>>
>> I would like to suggest that upon adoption, that this document go
>> through a TLS WG review of some sort before OPSAWG does a WGLC.
>>
>>
>> ___
>> TLS mailing list
>> t...@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Eric Rescorla]

On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann 
wrote:

> I actually think it's a pretty good summary, and delivers exactly what's
> promised in the title.  OTOH I can also see that it's going to get
> bikeshedded
> to death, and will probably never be editable into a form where people
> won't
> complain about it no matter how many changes are made.  Alternatively,
> it'll
> end up watered down to a point where no-one can complain any more but it
> won't
> say anything terribly useful by then.
>
> Perhaps it could be published as is with a comment that it represents the
> opinions of the authors?  Although given that it's Informational and not
> Standards-track or a BCP, that should be a given anyway.
>

Actually, no. Most IETF documents, even informational ones, bear a
statement that they have IETF Consensus.

See: https://tools.ietf.org/html/rfc5741#section-3.2.1

-Ekr


> Peter.
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Eric Rescorla's No Objection on draft-ietf-opsawg-mud-24: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



--
COMMENT:
--

Thanks for addressing my DISCUSS.

"  signature" and validating the signature across the MUD file.  The Key
   Usage Extension in the signing certificate MUST be present and have
   the bit digitalSignature(0) set.  When the id-pe-mudsigner extension
   is present in a device's X.509 certificate, the MUD signature file
   MUST have been generated by a certificate whose subject matches the
   contents of that id-pe-mudsigner extension. "

Isn't the extension required to be present.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-21.txt

[Eric Rescorla]

On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <l...@cisco.com> wrote:

> Hi EKR,
>
>
> On 18.05.18 19:57, Eric Rescorla wrote:
> > Eliot, > > The certificate part seems basically right (I think you
> should require specific KeyUsage bits).
> It's in there:
>
> It is expected that the Key Usage extension would contain "Digital
> Signature" and that the extended key usage would include either "code
> signing" or "email protection".
>
>
> This leaves a little a little flexibility.  I think this is sufficient,
> and compatible with existing CAs.
>

I disagree. This is going to lead to a lot of interop problems. You need to
actually specify the bits

> > Maybe I missed it, but I didn't see anything about the level of trust
you should have in cases where you can't reliably tie the endpoint's
transmissions to its certificate.
It's there but could be clearer:

OLD:

A
MUD manager MUST cease processing of that file it cannot validate the
chain of trust to a known trust anchor until an administrator has
given approval.


NEW:

A
MUD manager MUST cease processing of that file it cannot validate the
chain of trust to a known trust anchor or the MUDsigner until an
administrator has
given approval.


That is- throw an exception and let the admin sort it out.

This is about the file. I'm talking about IP/MAC forgery.

-Ekr


> Eliot
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-21.txt

[Eric Rescorla]

Eliot,

The certificate part seems basically right (I think you should require
specific KeyUsage bits).

Maybe I missed it, but I didn't see anything about the level of trust you
should have in cases where you can't reliably tie the endpoint's
transmissions to its certificate.

-Ekr


On Fri, May 18, 2018 at 3:46 AM, Joe Clarke  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chair hat on:
>
> We would like to give this call for review a week timeout with the WG.
>
> Please pay special attention to the security changes Eliot has
> described below when reviewing the new text.
>
> We are looking to push this forward EOD on May 25.
>
> Thanks.
>
> Joe
>
> On 5/17/18 11:36, Eliot Lear wrote:
> > Hi everyone,
> >
> > This draft is intended to address all IESG comments.  Thanks to the
> > IESG and reviewers for their contributions.  A summary of the
> > changes is below, but people may wish to do a side by side review.
> >
> > Eliot
> >
> >
> > * Small edits to the abstract * Clarity in the introduction that
> > the focus is on protecting the device. * Many grammatical/wording
> > improvements * Clarity when MUD is most effective. * MUD controller
> > -> MUD manager * Normative language boiler plate change * Clarity
> > on what should happen when a MUD manager can't reach a MUD file
> > server * A few reference updates * Clarity on the validity time of
> > a MUD file * Added references to RFCs 5911 and 5912 for SMI
> > changes * one additional data element (documentation) * one change
> > based on an update to the ACL model during its last call *
> > Subsection numbering for node descriptions. * Improved text around
> > "controller", direction-initiated. * Simplified MUD-URL text. *
> > Optional reserved space added to DHCP, LLDP options * Simplified
> > DHCP processing. * A new certificate field to bind the manufacturer
> > certificate to the mud signer. * A content type definition for the
> > SMI. * Updated security considerations.
> >
> >
>
> -BEGIN PGP SIGNATURE-
>
> iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWv6vBgAKCRBvaI+K/hTP
> hwzAAJ4gQdPZ93IFCwO7nWOca4gu7xbwkwCeJPLWlBoGGKDtuQp8sUHVJy+2lmY=
> =CyhD
> -END PGP SIGNATURE-
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear <l...@cisco.com> wrote:

> Hi Eric,
> On 16.04.18 14:25, Eric Rescorla wrote:
>
> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits into
> the system as a whole.
>
> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>
> - Additive -- it lets the device do things it otherwise might not be
> permitted to do (e.g., accept incoming TCP connections)
> - Restrictive -- it stops the device from doing things that it otherwise
> would be permitted to do (e.g., make connections to IP addresses on non-443
> ports)
>
>
> What you describe is the choice of the network administrator, and not the
> standard nor the manufacturer.  You are essentially asking, “what is the
> default policy?
>

No, I'm not asking that. What I'm looking for is the document to describe
the various use cases and ensure that the mechanisms it provides actually
be able to effect those use cases.



In the former case, it's very important not to be able to forge acceptable
> MUD policies, but in the latter case, an attacker can just not serve *any*
> MUD policy and be in a stronger position than they would be if they had a
> valid policy,[...]
>
>
> And so that will depend on the deployment.  And many of the attacks would
> be detectable.
>

How would those attacks be detectable?


I should mention one use case that I did think of, where additive would be
> immediately useful: "This device is made by the same manufacturer as
> another device (and hence they can talk to each other). However, I note
> that MUD is actually not capable of securely conveying that, because
> there's no proof that the device in hand actually is made by the
> manufacturer, only that it possesses a public credential for some device
> made by that manufacturer.
>
>
> That is the point of building out a PKI, and as I wrote, there are some
> interested in providing what amounts to a certification for this purpose.
> This is also something the MUD manager can take on: as time goes on it can
> white list signers, and it can flag devices that are not recognized as
> being risky.  In addition, if you have someone willing to take
> accountability for that device to lay a claim, it may not be "proof", but
> that is  good enough in an enterprise environment, where someone can be
> called to account for having added the device.
>

Well, there are two types of PKI here:

1. The one associated with the device certificate
2. The one associated with the MUD signature.

My point is that only the former provides any assurance that the actual
device has anything to do with the manufacturer. In the latter case, I can
just stuff the URL of any manufacturer's MUD policy in my device that I
please.

-Ekr
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

Hi Eliot,

Thanks for continuing the conversation. My question is how this fits into
the system as a whole.

ISTM that there are two ways in which a MUD policy can affect the network's
behavior:

- Additive -- it lets the device do things it otherwise might not be
permitted to do (e.g., accept incoming TCP connections)
- Restrictive -- it stops the device from doing things that it otherwise
would be permitted to do (e.g., make connections to IP addresses on non-443
ports)

In the former case, it's very important not to be able to forge acceptable
MUD policies, but in the latter case, an attacker can just not serve *any*
MUD policy and be in a stronger position than they would be if they had a
valid policy, Thus, it's only in the former (additive) case where forging a
policy is useful to the attacker, and, in fact, it seems like accepting an
unsigned MUD policy would be better than no policy. Given the ubiquity of
non-MUD devices and the relatively limited capabilities that MUD seems to
want to convey, it seems like the additive case isn't very useful.

I should mention one use case that I did think of, where additive would be
immediately useful: "This device is made by the same manufacturer as
another device (and hence they can talk to each other). However, I note
that MUD is actually not capable of securely conveying that, because
there's no proof that the device in hand actually is made by the
manufacturer, only that it possesses a public credential for some device
made by that manufacturer. So, I'm actually left wondering how that feature
is intended to work. I regret not catching this earlier, but perhaps you
could explain?

Thanks,
-Ekr


On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear <l...@cisco.com> wrote:

> Hi Eric,
>
> Trimming.
>
> On 15.04.18 21:22, Eric Rescorla wrote:
>
>
>
>
>
>> IMPORTANT
>>
>>  The certificate extension is described below.
>>
>>  The information returned by the MUD file server (a web server) is
>>  valid for the duration of the Thing's connection, or as specified in
>>  the description.  Thus if the Thing is disconnected, any associated
>>  configuration in the switch can be removed.  Similarly, from time to
>>
>> IMPORTANT: What does "disconnected" mean in this context? Does a
>> reboot count? What if I am wireless? This is a critical question if
>> MUD is intended as a post-compromise mechanism. Say that an attacker
>> compromises the firmware for a device and then forces a reboot
>> followed by a 2 hour pause before the wireless NIC is activated. Will
>> this result in configuration removal? If so, MUD seems of limited use,
>> because it can then make itself appear to be a new device with a new
>> MUD configuration. (This is of course true in general in a wireless
>> context if the firmware can change the client's L2 address).
>>
>>
>> Yes, configuration is intended to be removed when a device disconnects or
>> a session terminates.  This would be considered normal garbage collection.
>> But whether or not you can simply replace the firmware and gain the same
>> access will depend on how the MUD-URL is learned.  If it is in a
>> manufacturer certificate, for instance, that's not something an attacker
>> will easily replace.  If the assertion is coming via LLDP, or DHCP, then
>> one has to apply the mitigations discussed in the security considerations
>> section (and they are numerous).
>>
>
> I'm not following you here. Say it's in a manufacturer certificate, what
> stops me from getting my own certificate for Attacker LLC and then serving
> a wide open policy? The mitigations don't really seem to do much to
> counteract this.
>
>
> I believe this point and one down below, where you write:
>
> This doesn't seem to address my concern, which is that there's no
> realistic way of knowing
> what trust anchors apply. If it's not WebPKI, then what?
>
> are related, and so I propose to address them together, and this text
> could go into security considerations.  The *intent* is that mud managers
> or their providers will keep a list of known trusted signers.  Examples are
> likely to include certification bodies (we are aware of at least one that
> is very interested), the MUD manager vendor themselves, and perhaps
> others.  Because these are early days, I don't want to be too declarative,
> but we can say this:
>
> NEW:
>
> ---
> MUD managers and their administrators MUST NOT automatically trust a
> manufacturer's certificate simply because it validates.  Rather, the
> certificate MUST be signed by an entity that has previously established
> trust for this explicit purpose.  In particular, the WebPKI alone is not
> appropriate.
> ---
>
>

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Sun, Apr 15, 2018 at 10:28 AM, Eliot Lear <l...@cisco.com> wrote:

> Hi Eric,
>
> On 15.04.18 13:32, Eric Rescorla wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found 
> here:https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> DISCUSS:
> --
>
> Re-posted due to pilot error.
>
> Rich version of this review at:https://mozphab-ietf.devsvcdev.mozaws.net/D3106
>
>
> The threat model for MUD doesn't seem clear, at least to me. It seems
> like there are at least two potential threat models:  - Telling the
> network how to configure access control to prevent the device from
> being compromised - Telling the network how to configure access
> control the limit the damage in case a device is compromised (e.g.,
> avoiding its use in a botnet).  Are both of these in scope?  If so, the
> latter seems to need substantially more analysis -- and perhaps
> mechanism -- because it seems relatively easy for the attacker to
> evade access control limits once it has replaced the firmware on the
> device (as noted below). In either case, the document needs to be
> clear about this, whether in the security considerations or elsewhere.
>
>
> MUD is primarily intended to address the former, but provides some benefit
> against the latter in some cases.  In particular, MUD is intended to keep
> devices from getting infected in the first place.  As a side-effect, if a
> device *is* broken into, it may be possible to either prevent additional
> access, or otherwise detect the break-in based on a change in profile.  I
> propose to state this more clearly in the introduction, as follows:
>
> NEW:
>
> MUD primarily addresses threats to the device rather than the device as a
> threat.  In some circumstances, however, MUD may offer some protection in
> the latter case, depending on the MUD-URL is communicated, and how devices
> and their communications are authenticated.
>

LGTM


>
>
> IMPORTANT
>
>  The certificate extension is described below.
>
>  The information returned by the MUD file server (a web server) is
>  valid for the duration of the Thing's connection, or as specified in
>  the description.  Thus if the Thing is disconnected, any associated
>  configuration in the switch can be removed.  Similarly, from time to
>
> IMPORTANT: What does "disconnected" mean in this context? Does a
> reboot count? What if I am wireless? This is a critical question if
> MUD is intended as a post-compromise mechanism. Say that an attacker
> compromises the firmware for a device and then forces a reboot
> followed by a 2 hour pause before the wireless NIC is activated. Will
> this result in configuration removal? If so, MUD seems of limited use,
> because it can then make itself appear to be a new device with a new
> MUD configuration. (This is of course true in general in a wireless
> context if the firmware can change the client's L2 address).
>
>
> Yes, configuration is intended to be removed when a device disconnects or
> a session terminates.  This would be considered normal garbage collection..
> But whether or not you can simply replace the firmware and gain the same
> access will depend on how the MUD-URL is learned.  If it is in a
> manufacturer certificate, for instance, that's not something an attacker
> will easily replace.  If the assertion is coming via LLDP, or DHCP, then
> one has to apply the mitigations discussed in the security considerations
> section (and they are numerous).
>

I'm not following you here. Say it's in a manufacturer certificate, what
stops me from getting my own certificate for Attacker LLC and then serving
a wide open policy? The mitigations don't really seem to do much to
counteract this.


>  The MUD URL identifies a Thing with a specificity according to the
>  manufacturer's wishes.  It could include a brand name, model number,
>  or something more specific.  It also could provide a means to
>  indicate what version the product is.
>
> IMPORTANT: Are you just using "identify" loosely here? I see how it
> can be *based* on those characteristics, but absent a schema it
&g

[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



--
DISCUSS:
--

Re-posted due to pilot error.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>  The certificate extension is described below.
>
>  The information returned by the MUD file server (a web server) is
>  valid for the duration of the Thing's connection, or as specified in
>  the description.  Thus if the Thing is disconnected, any associated
>  configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>https://example.com/lightbulbs/colour/v1
>
>  The MUD URL identifies a Thing with a specificity according to the
>  manufacturer's wishes.  It could include a brand name, model number,
>  or something more specific.  It also could provide a means to
>  indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>-in mudfile -binary -outform DER - \
>-certfile intermediatecert -out mudfile.p7s
>
>  Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.


--
COMMENT:
--


>
>   Abstract
>
>  This memo specifies a component-based architecture for manufacturer
>  usage descriptions (MUD).  The goal of MUD is to provide a means for
>  Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>  it continues to make sense for general purpose computing devices
>  today, including laptops, smart phones, and tablets.
>
>  [RFC7452] discusses design patterns for, and poses questions about,
>  smart objects.  Let us then posit a group of objects that are
>  specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>

[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



--
DISCUSS:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>  The certificate extension is described below.
>
>  The information returned by the MUD file server (a web server) is
>  valid for the duration of the Thing's connection, or as specified in
>  the description.  Thus if the Thing is disconnected, any associated
>  configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as an access control mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>https://example.com/lightbulbs/colour/v1
>
>  The MUD URL identifies a Thing with a specificity according to the
>  manufacturer's wishes.  It could include a brand name, model number,
>  or something more specific.  It also could provide a means to
>  indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>-in mudfile -binary -outform DER - \
>-certfile intermediatecert -out mudfile.p7s
>
>  Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.


--
COMMENT:
--


>
>   Abstract
>
>  This memo specifies a component-based architecture for manufacturer
>  usage descriptions (MUD).  The goal of MUD is to provide a means for
>  Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>  it continues to make sense for general purpose computing devices
>  today, including laptops, smart phones, and tablets.
>
>  [RFC7452] discusses design patterns for, and poses questions about,
>  smart objects.  Let us then posit a group of objects that are
>  specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>  specifically not general pur

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

Thanks for your response. I am OK with your proposed changes. Warren, I
think we're done.

-Ekr

On Thu, Mar 15, 2018 at 6:16 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hi EKR,
>
> I'll assume you're happy with the previous responses.  These are all
> new comments and have been responded to and addressed.
>
> I requested that the updated version be posted pending approval.
> Responses  inline.
>
> On Wed, Mar 14, 2018 at 8:36 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > I have reviewed the new version. Thanks for incorporating my comments.
> >
> > I have two substantive comment and a bunch of editorial suggestions. LMK
> if
> > you
> > would like me to put this in the tracker.
> >
> >
> > SUBSTANTIVE
> >
> >for attack traffic, meeting regulatory requirements, or for other
> >purposes.  The implications for enterprises, who own the data on
> >their networks is very different from service providers who may be
> >
> > I don't believe that this is an accurate characterization of the
> > relationship between employees and enterprises. It may be that my
> > employer forbids me to access Facebook but that doesn't give them
> > ownership of my FB data. Perhaps "enterprises, whose networks are
> > often only made accessible for business purposes"
>
> You are typically subject to monitoring of all traffic from a company
> network by policy and a signed agreement at the time of employment (at
> least in the US).  Many companies exclude financial site access as not
> to expose PII, but not social media and sharing platforms as that's an
> easy mechanism to exfiltrate data.
>
> These sites are still accessible, just monitored, so I wouldn't want
> to falsely change the text to say the network is only available for
> business purposes.  I would personally advise people to follow that
> practice at work though.
>
> I made the following edits to consider the outbound access of a user
> in the description of data.  The original text was focused on the
> corporate data and resources.
>
> "The implications for enterprises, who own the data on their networks
> or have explicit agreements that permit monitoring of user traffic is
> very different from service providers who may be accessing content
> that violates privacy considerations."
>

Thanks. This seems fine.


>
> >only the headers exposed for the data-link, network, and transport
> >layers.  Delving deeper into packets is possible, but there is
> >typically a high degree of accuracy from the header information and
> >
> > I don't believe this is accurate either. Sandvine-type DPI devices are
> > certainly intended for SPs.
>
> The text says, "Delving deeper is possible", so that covers your
> example.  The text is from Chris Morrow who has quite a bit of
> operator experience into what actually happens in service provider
> networks.   This text akcs that DPI is possible, but states that the
> more often used information from packet streams is limited to header
> information from link, network, and transport layers.  A continued
> shift in this direction bodes well for end-to-end.
>
> No change made here.
>

OK.

>
>
> >
> >
> > EDITORIAL
> >
> >negotiation process resulting in fallback to the use of clear text.
> >There has already been documented cases of service providers
> >preventing STARTTLS to prevent session encryption negotiation on some
> > Nit: have already.
> >
> Changed, thanks.
> >
> >
> >session to inject a super cookie to enable tracking of users for
> >advertisers, also considered an attack.  These serves as examples of
> >undesirable behavior that could be prevented through upfront
> > Nit: serve as
> >
> Changed, thanks.
> >
> >
> >
> >their networks is very different from service providers who may be
> >accessing content that violates privacy considerations.
> >Additionally, service provider equipment is designed for accessing
> > perhaps "in a way that violates"
> >
> Changed, thanks.
> >
> >
> >
> >
> >supporting protocols (e.g., DNS, DHCP), network and transport (e.g.,
> >IP, TCP), and some higher layer protocols (e.g., RTP, RTCP).
> >Troubleshooting will move closer to the endpoint with increased
> > They don't do HTTP inspection?
> >
>
> This is again from Chris Morrow and the statement says generally
> limited to supporting protocols.  That's meant to mean these are the
> most common.  It doesn't exc

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

I have reviewed the new version. Thanks for incorporating my comments.

I have two substantive comment and a bunch of editorial suggestions. LMK if
you
would like me to put this in the tracker.


SUBSTANTIVE

   for attack traffic, meeting regulatory requirements, or for other
   purposes.  The implications for enterprises, who own the data on
   their networks is very different from service providers who may be

I don't believe that this is an accurate characterization of the
relationship between employees and enterprises. It may be that my
employer forbids me to access Facebook but that doesn't give them
ownership of my FB data. Perhaps "enterprises, whose networks are
often only made accessible for business purposes"

   only the headers exposed for the data-link, network, and transport
   layers.  Delving deeper into packets is possible, but there is
   typically a high degree of accuracy from the header information and

I don't believe this is accurate either. Sandvine-type DPI devices are
certainly intended for SPs.


EDITORIAL

   negotiation process resulting in fallback to the use of clear text.
   There has already been documented cases of service providers
   preventing STARTTLS to prevent session encryption negotiation on some
Nit: have already.



   session to inject a super cookie to enable tracking of users for
   advertisers, also considered an attack.  These serves as examples of
   undesirable behavior that could be prevented through upfront
Nit: serve as




   their networks is very different from service providers who may be
   accessing content that violates privacy considerations.
   Additionally, service provider equipment is designed for accessing
perhaps "in a way that violates"





   supporting protocols (e.g., DNS, DHCP), network and transport (e.g.,
   IP, TCP), and some higher layer protocols (e.g., RTP, RTCP).
   Troubleshooting will move closer to the endpoint with increased
They don't do HTTP inspection?



   A gap exists for vendors where built-in diagnostics and
   serviceability is not adequate to provide detailed logging and
   debugging capabilities that, when possible, can access cleartext
Nit: "are not"



   debugging capabilities that, when possible, can access cleartext
   network parameters.  In addition to traditional logging and debugging
   methods, packet tracing and inspection along the service path
I think you've got some sort of agreement problem here. It's not the
capabilities that can access plaintext.



   filters content based on a blacklist of sites or based on the user's
   pre-defined profile (e.g. for age sensitive content).  Although
   filtering can be done by many methods, one commonly used method
Nit: "e.g.,"



   encryption that prevents monitoring via interception, while providing
   forward secrecy.
This text is unobjectionable but perhaps not maximally clear. Perhaps:

"A number of these tools provide passive decryption by providing the
monitoring device with the server's private key. The move to increased use
of of forward-secret key exchange mechanism impacts the use of these
techniques".



   more effective at preventing malware from entering the network.  Some
   enterprises may be more aggessive in their filtering and monitoring
   policy, causing undesirable outcomes.  Web filtering solutions
Nit: aggressive.



   encrypted.  Multiplexed formats (such as HTTP/2 and QUIC)  may however incorporate several application
   streams over one connection, which makes the bitrate/pacing no longer
Something went wrong with your reference here.



   user IP flows, deploying them would require enhancing them with
   tunnel translation, tunnel management functions etc..
Nit: extra period



  Society, "The Security Impact of HTTPS Interception",
  2017.
You seem to have lost the authors names here.


On Wed, Mar 14, 2018 at 8:04 AM, Warren Kumari <war...@kumari.net> wrote:

>
> On Wed, Mar 14, 2018 at 10:12 AM Eric Rescorla <e...@rtfm.com> wrote:
>
>> Hi Warren,
>>
>> I am on travel today, but I expect to read this today or Friday. Can you
>> give me until Saturday?
>>
>
> Sure.
> W
>
>
>> Thanks,
>> -Ekr
>>
>>
>> On Wed, Mar 14, 2018 at 7:07 AM, Warren Kumari <war...@kumari.net> wrote:
>>
>>> EKR,
>>> I'm planning on clicking the "This document is approved" button before
>>> the IETF101 meeting unless I hear a clear signal that there is
>>> something that you *cannot* live with.
>>>
>>> Thank you again for your Abstain and all of your comments on the
>>> document,
>>> W
>>>
>>> On Mon, Mar 5, 2018 at 10:58 AM, Warren Kumari <war...@kumari.net>
>>> wrote:
>>> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla <e...@r

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

Hi Warren,

I am on travel today, but I expect to read this today or Friday. Can you
give me until Saturday?

Thanks,
-Ekr


On Wed, Mar 14, 2018 at 7:07 AM, Warren Kumari <war...@kumari.net> wrote:

> EKR,
> I'm planning on clicking the "This document is approved" button before
> the IETF101 meeting unless I hear a clear signal that there is
> something that you *cannot* live with.
>
> Thank you again for your Abstain and all of your comments on the document,
> W
>
> On Mon, Mar 5, 2018 at 10:58 AM, Warren Kumari <war...@kumari.net> wrote:
> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla <e...@rtfm.com> wrote:
> >>
> >>
> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <war...@kumari.net>
> wrote:
> >>>
> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
> >>> <spencerdawkins.i...@gmail.com> wrote:
> >>> > Hi, Benoit,
> >>> >
> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise <bcla...@cisco.com>
> >>> > wrote:
> >>> >>
> >>> >> The way I see it, we're going to fix comments forever.
> >>> >
> >>> >
> >>> > Right. But my concern was that the text that we're reading for an
> >>> > up/down
> >>> > vote can change after we read it, so I should be tracking the
> proposed
> >>> > text
> >>> > changes.
> >>>
> >>> [ Updating in the middle of the thread as this seems the logical entry
> >>> point ]
> >>>
> >>> ... so, we are not updating the current version (we wanted 7 days for
> >>> people to read it), and so will be (I believe) balloting on that --
> >>> but, just like any other document we ballot on, the RAD will pay
> >>> attention to comments received and "Do the right thing".
> >>>
> >>> I believe that EKRs comments are helpful, and Kathleen hopes to
> >>> address / incorporate them before the call. I will be putting both the
> >>> current (being balloted on) and updated version in GitHub (for a
> >>> friendly web enabled diff) so that people can see what the final
> >>> version will actually look like.
> >>> So, I guess we are formally balloting (unless the DISCUSS is cleared)
> >>> on the text as written (-22), but with an understanding that the AD
> >>> will make it look like the version in GitHub before taking off the
> >>> Approved, Revised ID needed / AD follow-up flag.
> >>>
> >>> Confused yet? :-P
> >>
> >>
> >> Hi Warren,
> >>
> >> Thanks for this note.
> >>
> >> It's too bad that we aren't able to see the proposed revisions at this
> >> point, but I appreciate your commitment to working through the
> >> remaining issues, and I think we should be able to reach a
> >> satisfactory resolution.
> >
> > I appreciate your Abstain, but, as mentioned, I'm committed to making
> > sure that the right thing happens here - a new version of the document
> > (-24) was posted on Friday; I believe that it is now acceptable, and
> > Paul (the document shepherd) also kindly looked through your comments
> > and the changes and thinks it's OK.
> >
> > I'm sure that you are tired of this by now, but please take a look at
> > the diffs (stuffed in GitHub
> > (https://github.com/wkumari/effect-encrypt/commit/974db6cb13
> faecbf5b1704c1da580b320843d0b3)
> > or on the IETF site
> > (https://www.ietf.org/rfcdiff?url1=draft-mm-wg-effect-encryp
> t-22=draft-mm-wg-effect-encrypt-24)
> > and let mw know if the document is something you can live with...
> >
> > W
> >
> >
> >>  In the interest of not forcing everyone to
> >> read the document by tomorrow, I'm going to change my ballot to
> >> Abstain.
> >>
> >> Best,
> >> -Ekr
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>> >
> >>> > That doesn't seem up/down. It seems like every other draft I've
> balloted
> >>> > on
> >>> > as an AD :-)
> >>> >
> >>>
> >>> Indeed.
> >>> W
> >>>
> >>> > Spencer
> >>> >
> >>> >>
> >>> >> And we need to resolve this one before the current ADs step down.
> >>> >>
> >>> >> Re

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

Thank you.

-Ekr


On Wed, Feb 28, 2018 at 9:06 AM, Warren Kumari <war...@kumari.net> wrote:

> On Wed, Feb 28, 2018 at 11:49 AM, Eric Rescorla <e...@rtfm.com> wrote:
> > No worries. Looking forward to your thoughts on my comments.
> >
>
> Me too! I've created a repo
> (https://github.com/wkumari/effect-encrypt) where I'll be placing the
> new version to all for easier viewing / diffs.
>
> W
>
>
> > -Ekr
> >
> >
> > On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty
> > <kathleen.moriarty.i...@gmail.com> wrote:
> >>
> >> Sorry, I wasn’t able to task switch to editing the document yesterday
> with
> >> other work obligations.
> >>
> >> Best,
> >> Kathleen
> >>
> >> Sent from my mobile device
> >>
> >> On Feb 28, 2018, at 9:45 AM, Eric Rescorla <e...@rtfm.com> wrote:
> >>
> >>
> >>
> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <war...@kumari.net>
> wrote:
> >>>
> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
> >>> <spencerdawkins.i...@gmail.com> wrote:
> >>> > Hi, Benoit,
> >>> >
> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise <bcla...@cisco.com>
> >>> > wrote:
> >>> >>
> >>> >> The way I see it, we're going to fix comments forever.
> >>> >
> >>> >
> >>> > Right. But my concern was that the text that we're reading for an
> >>> > up/down
> >>> > vote can change after we read it, so I should be tracking the
> proposed
> >>> > text
> >>> > changes.
> >>>
> >>> [ Updating in the middle of the thread as this seems the logical entry
> >>> point ]
> >>>
> >>> ... so, we are not updating the current version (we wanted 7 days for
> >>> people to read it), and so will be (I believe) balloting on that --
> >>> but, just like any other document we ballot on, the RAD will pay
> >>> attention to comments received and "Do the right thing".
> >>>
> >>> I believe that EKRs comments are helpful, and Kathleen hopes to
> >>> address / incorporate them before the call. I will be putting both the
> >>> current (being balloted on) and updated version in GitHub (for a
> >>> friendly web enabled diff) so that people can see what the final
> >>> version will actually look like.
> >>> So, I guess we are formally balloting (unless the DISCUSS is cleared)
> >>> on the text as written (-22), but with an understanding that the AD
> >>> will make it look like the version in GitHub before taking off the
> >>> Approved, Revised ID needed / AD follow-up flag.
> >>>
> >>> Confused yet? :-P
> >>
> >>
> >> Hi Warren,
> >>
> >> Thanks for this note.
> >>
> >> It's too bad that we aren't able to see the proposed revisions at this
> >> point, but I appreciate your commitment to working through the
> >> remaining issues, and I think we should be able to reach a
> >> satisfactory resolution. In the interest of not forcing everyone to
> >> read the document by tomorrow, I'm going to change my ballot to
> >> Abstain.
> >>
> >> Best,
> >> -Ekr
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>> >
> >>> > That doesn't seem up/down. It seems like every other draft I've
> >>> > balloted on
> >>> > as an AD :-)
> >>> >
> >>>
> >>> Indeed.
> >>> W
> >>>
> >>> > Spencer
> >>> >
> >>> >>
> >>> >> And we need to resolve this one before the current ADs step down.
> >>> >>
> >>> >> Regards, Benoit
> >>> >>
> >>> >> This may not be my week, when it comes to comprehension. At least,
> I'm
> >>> >> 0
> >>> >> for 2 so far today.
> >>> >>
> >>> >> Are we still tuning text in this draft?
> >>> >>
> >>> >> https://www.ietf.org/standards/process/iesg-ballots/ says that the
> >>> >> alternate balloting procedure is an up/down vote - we either agree
> to
> >>> >> publish, or agree to send a docume

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

No worries. Looking forward to your thoughts on my comments.

-Ekr


On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Sorry, I wasn’t able to task switch to editing the document yesterday with
> other work obligations.
>
> Best,
> Kathleen
>
> Sent from my mobile device
>
> On Feb 28, 2018, at 9:45 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
>
> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <war...@kumari.net> wrote:
>
>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>> <spencerdawkins.i...@gmail.com> wrote:
>> > Hi, Benoit,
>> >
>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise <bcla...@cisco.com>
>> wrote:
>> >>
>> >> The way I see it, we're going to fix comments forever.
>> >
>> >
>> > Right. But my concern was that the text that we're reading for an
>> up/down
>> > vote can change after we read it, so I should be tracking the proposed
>> text
>> > changes.
>>
>> [ Updating in the middle of the thread as this seems the logical entry
>> point ]
>>
>> ... so, we are not updating the current version (we wanted 7 days for
>> people to read it), and so will be (I believe) balloting on that --
>> but, just like any other document we ballot on, the RAD will pay
>> attention to comments received and "Do the right thing".
>>
>> I believe that EKRs comments are helpful, and Kathleen hopes to
>> address / incorporate them before the call. I will be putting both the
>> current (being balloted on) and updated version in GitHub (for a
>> friendly web enabled diff) so that people can see what the final
>> version will actually look like.
>> So, I guess we are formally balloting (unless the DISCUSS is cleared)
>> on the text as written (-22), but with an understanding that the AD
>> will make it look like the version in GitHub before taking off the
>> Approved, Revised ID needed / AD follow-up flag.
>>
>> Confused yet? :-P
>>
>
> Hi Warren,
>
> Thanks for this note.
>
> It's too bad that we aren't able to see the proposed revisions at this
> point, but I appreciate your commitment to working through the
> remaining issues, and I think we should be able to reach a
> satisfactory resolution. In the interest of not forcing everyone to
> read the document by tomorrow, I'm going to change my ballot to
> Abstain.
>
> Best,
> -Ekr
>
>
>
>
>
>
>
>>
>>
>> >
>> > That doesn't seem up/down. It seems like every other draft I've
>> balloted on
>> > as an AD :-)
>> >
>>
>> Indeed.
>> W
>>
>> > Spencer
>> >
>> >>
>> >> And we need to resolve this one before the current ADs step down.
>> >>
>> >> Regards, Benoit
>> >>
>> >> This may not be my week, when it comes to comprehension. At least, I'm
>> 0
>> >> for 2 so far today.
>> >>
>> >> Are we still tuning text in this draft?
>> >>
>> >> https://www.ietf.org/standards/process/iesg-ballots/ says that the
>> >> alternate balloting procedure is an up/down vote - we either agree to
>> >> publish, or agree to send a document off for rework.
>> >>
>> >> If we're still resolving comments, one can imagine that we'd get to a
>> >> one-Discuss situation, or even no Discusses, and wouldn't be doing an
>> >> Alternate Ballot on Thursday.
>> >>
>> >> I don't object to resolving comments (actually, I find that lovely),
>> but I
>> >> don't know what we're doing.
>> >>
>> >> I've never seen the alternate balloting procedure executed (either as
>> IESG
>> >> scribe or as an IESG member), so maybe I don't get it, and other
>> people have
>> >> different expectations.
>> >>
>> >> Spencer
>> >>
>> >>
>> >> ___
>> >> OPSAWG mailing list
>> >> OPSAWG@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/opsawg
>> >>
>> >>
>> >
>> >
>> > ___
>> > OPSAWG mailing list
>> > OPSAWG@ietf.org
>> > https://www.ietf.org/mailman/listinfo/opsawg
>> >
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>---maf
>>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:

> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>  wrote:
> > Hi, Benoit,
> >
> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
> wrote:
> >>
> >> The way I see it, we're going to fix comments forever.
> >
> >
> > Right. But my concern was that the text that we're reading for an up/down
> > vote can change after we read it, so I should be tracking the proposed
> text
> > changes.
>
> [ Updating in the middle of the thread as this seems the logical entry
> point ]
>
> ... so, we are not updating the current version (we wanted 7 days for
> people to read it), and so will be (I believe) balloting on that --
> but, just like any other document we ballot on, the RAD will pay
> attention to comments received and "Do the right thing".
>
> I believe that EKRs comments are helpful, and Kathleen hopes to
> address / incorporate them before the call. I will be putting both the
> current (being balloted on) and updated version in GitHub (for a
> friendly web enabled diff) so that people can see what the final
> version will actually look like.
> So, I guess we are formally balloting (unless the DISCUSS is cleared)
> on the text as written (-22), but with an understanding that the AD
> will make it look like the version in GitHub before taking off the
> Approved, Revised ID needed / AD follow-up flag.
>
> Confused yet? :-P
>

Hi Warren,

Thanks for this note.

It's too bad that we aren't able to see the proposed revisions at this
point, but I appreciate your commitment to working through the
remaining issues, and I think we should be able to reach a
satisfactory resolution. In the interest of not forcing everyone to
read the document by tomorrow, I'm going to change my ballot to
Abstain.

Best,
-Ekr







>
>
> >
> > That doesn't seem up/down. It seems like every other draft I've balloted
> on
> > as an AD :-)
> >
>
> Indeed.
> W
>
> > Spencer
> >
> >>
> >> And we need to resolve this one before the current ADs step down.
> >>
> >> Regards, Benoit
> >>
> >> This may not be my week, when it comes to comprehension. At least, I'm 0
> >> for 2 so far today.
> >>
> >> Are we still tuning text in this draft?
> >>
> >> https://www.ietf.org/standards/process/iesg-ballots/ says that the
> >> alternate balloting procedure is an up/down vote - we either agree to
> >> publish, or agree to send a document off for rework.
> >>
> >> If we're still resolving comments, one can imagine that we'd get to a
> >> one-Discuss situation, or even no Discusses, and wouldn't be doing an
> >> Alternate Ballot on Thursday.
> >>
> >> I don't object to resolving comments (actually, I find that lovely),
> but I
> >> don't know what we're doing.
> >>
> >> I've never seen the alternate balloting procedure executed (either as
> IESG
> >> scribe or as an IESG member), so maybe I don't get it, and other people
> have
> >> different expectations.
> >>
> >> Spencer
> >>
> >>
> >> ___
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >>
> >
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:

> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>  wrote:
> > Hi, Benoit,
> >
> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
> wrote:
> >>
> >> The way I see it, we're going to fix comments forever.
> >
> >
> > Right. But my concern was that the text that we're reading for an up/down
> > vote can change after we read it, so I should be tracking the proposed
> text
> > changes.
>
> [ Updating in the middle of the thread as this seems the logical entry
> point ]
>
> ... so, we are not updating the current version (we wanted 7 days for
> people to read it), and so will be (I believe) balloting on that --
> but, just like any other document we ballot on, the RAD will pay
> attention to comments received and "Do the right thing".
>
> I believe that EKRs comments are helpful, and Kathleen hopes to
> address / incorporate them before the call. I will be putting both the
> current (being balloted on) and updated version in GitHub (for a
> friendly web enabled diff) so that people can see what the final
> version will actually look like.
> So, I guess we are formally balloting (unless the DISCUSS is cleared)
> on the text as written (-22), but with an understanding that the AD
> will make it look like the version in GitHub before taking off the
> Approved, Revised ID needed / AD follow-up flag.
>

Can you send a link to the Github version? I didn't see a reference?

-Ekr


>
> Confused yet? :-P
>
>
> >
> > That doesn't seem up/down. It seems like every other draft I've balloted
> on
> > as an AD :-)
> >
>
> Indeed.
> W
>
> > Spencer
> >
> >>
> >> And we need to resolve this one before the current ADs step down.
> >>
> >> Regards, Benoit
> >>
> >> This may not be my week, when it comes to comprehension. At least, I'm 0
> >> for 2 so far today.
> >>
> >> Are we still tuning text in this draft?
> >>
> >> https://www.ietf.org/standards/process/iesg-ballots/ says that the
> >> alternate balloting procedure is an up/down vote - we either agree to
> >> publish, or agree to send a document off for rework.
> >>
> >> If we're still resolving comments, one can imagine that we'd get to a
> >> one-Discuss situation, or even no Discusses, and wouldn't be doing an
> >> Alternate Ballot on Thursday.
> >>
> >> I don't object to resolving comments (actually, I find that lovely),
> but I
> >> don't know what we're doing.
> >>
> >> I've never seen the alternate balloting procedure executed (either as
> IESG
> >> scribe or as an IESG member), so maybe I don't get it, and other people
> have
> >> different expectations.
> >>
> >> Spencer
> >>
> >>
> >> ___
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >>
> >
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

Thanks for the updated draft. Some responses below.


On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

>
> >
> > DISCUSS
> >session encryption that deployed more easily instead of no
> >encryption.
> >
> > I think I understand what you are saying here, but the term
> > "breakable" seems very unfortunate, especially in the context of this
> > document. The only such shift I am aware of that has received
> > acceptance in IETF is one from always requiring fully authenticated
> > encryption to allowing unauthenticated encryption, which you document
> > in the next paragraph. I recognize that there are other perspectives
> > (e.g., those in draft-rhrd) but those are pretty far from IETF
> > consenus. Accordingly, I think you should remove this sentence.
>
> Opportunistic security was well discussed, so that was likely top of
> mind for you when reading this draft. However there are other areas
> where the IETF decided breakable encryption was better than none in
> recent years.  Another adopted and published example is in the mail
> community.  Deprecating MD5 was deemed to be too hard because of
> support in a particular library.  We had lengthy discussions about
> this for RFC7627 (see sect 6.2) and related drafts, now published
> RFCs.
>

I continue to think that the term "breakable" is very unfortunate here
(and of course, MD5 isn't breakable "encryption").

It seems to me that there are four areas where one might think that
compromises ought to be made:

1. Not deploying comsec at all because it's too hard (you allude to this
later).
2. Not deprecating weak algorithms because they are already deployed
(the case of MD5 and the like)
3. Rolling out unauthenticated or opportunistic encryption.
4. Rolling out weak algorithms rather than strong ones.

I agree we do 1-3, but my experience is we try pretty hard to avoid #4, and
that's how I read "breakable encryption". It's also generally not easier
to deploy. I think a better way to phrase this would be to say something
like:

"Perspectives on encryption paradigms have shifted over time to
incorporporate
ease of deployment as a high priority, and balance that against providing
the
maximum possible level of security regardless of deployment considerations"


> >motivation outside of privacy and pervasive monitoring that are
> >driving end-to-end encryption for these content providers.
> >
> > This section seems kind of confusing, at least as applied to
> > HTTP. There are three kinds of cache in HTTP:
> >
> > - Reverse proxy caches (the kind CDNs run)
> > - Explicit forward proxy caches
> > - "Transparent" intercepting caches
> >
> > The first of these move to HTTPS just fine and that's typically how
> > CDNs do it.  Explicit forward proxy caches are largely going away, but
> > part of the point of this kind of end-to-end encryption is to hide
> > data from those caches.
>
> Sure, that point was made in the draft and cleared up a little further
> from Benjamin K's review.  The business risk associated with not
> controlling your content was more explicitly stated for CDNs who have
> moved to an e2e approach.
>
> Here's the updated sentence:
>The business risk of losing control of content is a motivation outside
>of privacy and pervasive monitoring that are driving end-to-end
>encryption for these content providers.
>


> > Transparent intercepting caches that the user
> > didn't opt into are a bad thing, so having them go away is a positive.
>
> The text says authorized parties, so this is referring to caches where
> there is an agreement in place for this usage.


It says "authorized parties acting on their behalf", but it's not clear to
me on whose behalf. There is a sharp distinction here between the
network operator and the user. Who did you have in mind?



>   CDN's that wish to
> block this behavior have the option to require e2e.  That trend alone
> may be enough to kill this type of service offering.  I don't see why
> it shouldn't be mentioned in terms of it's current use.  What change
> are you looking to see here?
>

I see you added the following text

   It should be noted that caching was first supported in [RFC1945] and
   continued in the recent update of "Hypertext Transfer Protocol
   (HTTP/1.1): Caching" in [RFC7234].

I would rewrite this:

   It should be noted that explicit caching was first supported in
[RFC1945] and
   continued in the recent update of "Hypertext Transfer Protocol
   (HTTP/1.1): Caching" in [RFC7234]. Some operators also operate
   transparent caches which neither the user nor the origin opt-in to.
   The use of these caches is controversial within IETF and is generally
   precluded by the use of HTTPS.






>
> >
> >document existing practices, the development of IETF protocols
> >follows the guiding principles of [RFC1984] and [RFC2804].
> >
> > This is pretty opaque in this context. It should explicitly state that
> > the IETF's 

[OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-mm-wg-effect-encrypt-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/



--
DISCUSS:
--

I have completely re-reviewed the latest version. First, I want to
thank you for toning down some of the material that I was concerned
about.

Unfortunately, the fundamental concern that motivated my DISCUSS
remains: I do not believe that this document matches the consensus
of the IETF community.

Specifically, this document takes at face value a large number of
claims about the necessity/value of certain practices that either are
controversial within the IETF or that there is, I believe, rough
consensus to be actively bad, and that in many cases, encryption is
specifically designed to prevent. I have noted a number of these
below, but I do not believe that this is an exhaustive list (going
through my previous DISCUSS, I see that I noted a number of these but
that still appear to be unaddressed.)


DISCUSS
   session encryption that deployed more easily instead of no
   encryption.

I think I understand what you are saying here, but the term
"breakable" seems very unfortunate, especially in the context of this
document. The only such shift I am aware of that has received
acceptance in IETF is one from always requiring fully authenticated
encryption to allowing unauthenticated encryption, which you document
in the next paragraph. I recognize that there are other perspectives
(e.g., those in draft-rhrd) but those are pretty far from IETF
consenus. Accordingly, I think you should remove this sentence.


   motivation outside of privacy and pervasive monitoring that are
   driving end-to-end encryption for these content providers.

This section seems kind of confusing, at least as applied to
HTTP. There are three kinds of cache in HTTP:

- Reverse proxy caches (the kind CDNs run)
- Explicit forward proxy caches
- "Transparent" intercepting caches

The first of these move to HTTPS just fine and that's typically how
CDNs do it.  Explicit forward proxy caches are largely going away, but
part of the point of this kind of end-to-end encryption is to hide
data from those caches.  Transparent intercepting caches that the user
didn't opt into are a bad thing, so having them go away is a positive.

   document existing practices, the development of IETF protocols
   follows the guiding principles of [RFC1984] and [RFC2804].

This is pretty opaque in this context. It should explicitly state that
the IETF's position is that we do not engineer for these use cases,
not just to cite the RFCs.


   based billing, or for other reasons, possibly considered
   inappropriate by some.  See RFC7754 [RFC7754] for a survey of
   Internet filtering techniques and motivations.  This section is

I don't think this accurately represents the RFC, which makes clear
that the IAB consensus is that filtering is bad:

" From a technical perspective, there are no perfect or even good
solutions -- there is only least bad.  On that front, we posit that a
hybrid approach that combines endpoint-based filtering with network
filtering may prove least damaging.  An endpoint may choose to
participate in a filtering regime in exchange for the network
providing broader unfiltered access."


   detect or prevent attacks as well as to guarantee service level
   expectations.  In some cases, alternate options are available when
   encryption is in use, but techniques like that of data leakage

These certainly are use cases, but you really need to acknowledge that
it's also a form of user surveillance.


   Some DLP tools intercept traffic at the Internet gateway or proxy
   services with the ability to man-in-the-middle (MiTM) encrypted
   session traffic (HTTP/TLS).  These tools may use key words important
   to the enterprise including business sensitive information such as
   trade secrets, financial data, personally identifiable information
   (PII), or personal health information (PHI).  Various techniques are
   used to intercept HTTP/TLS sessions for DLP and other purposes, and
   are described in "Summarizing Known Attacks on TLS and DTLS"
   [RFC7457].

As far as I know, the MITM techniques used by middleboxes are not
described in 7457.

You also need to cover the fact that these MITM are a threat to user
security because they are often so badly implemented.


S 5.4.
It's pretty odd to talk about phishing without ac