[OPSAWG] New Version Notification - draft-mm-wg-effect-encrypt-21.txt

[internet-drafts]

A new version (-21) has been submitted for draft-mm-wg-effect-encrypt:
https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-21.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-21

Please note that it may take a couple of minutes from the time of submission
until the diff is available at tools.ietf.org.

IETF Secretariat.

___
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)

[Kathleen Moriarty]

Hi Eric,

Thanks for your feedback, responses are inline.

FYI - I posted another version, but expect at least one more iteration
after this version with additional comments and the ones we haven't
gotten to yet.

On Thu, Feb 8, 2018 at 12:04 AM, Eric Rescorla  wrote:
> 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.)

In the previous round of IESG reviews, the IESG concluded that framing
upfront was the preferred approach to make it clear that not all cited
practices are ones the IETF consider valid.  This was done in the
updated introduction.

Please respond to the discussion points as I believe your additional
points have been addressed to also make these points again in the
document.  In a couple of places, we have questions to make sure your
concern is understood.

>
>
> 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.

This sentence had nothing to do with the drafts that are not WG drafts
in the TLS WG, but real use cases of published RFCs where deprecated
crypto is still accepted despite efforts to correct that in addition
to the acceptance of the OS approach in multiple session encryption
protocols.  The support tools and use cases don't always drive the
best solution where we have strong crypto everywhere as you have also
noted on recent draft reviews, now published RFCs.

>
>
>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 

Re: [OPSAWG] draft-ietf-opsawg-mud

[Eliot Lear]

Yes, but they're not quite ready for release (I know of at least two). 
I think they're waiting for this doc to get finished.


On 19.02.18 19:07, Marco Davids (SIDN) wrote:
> Op 19-02-18 om 17:38 schreef Eliot Lear:
>
>>> I know of some
>>> people working to implement this.  I don't think they are all on this
>>> list.  Have you run this by them to see if this limits any use cases
>>> out of the box?
>>
>> I have.  I think they're okay with it.  
> Anyone knows if these implementations-in-the-making are to be admired
> as open source somewhere on-line?
>
> -- 
> Marco
>
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg



signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] draft-ietf-opsawg-mud

[Marco Davids (SIDN)]

Op 19-02-18 om 17:38 schreef Eliot Lear:


I know of some
people working to implement this.  I don't think they are all on this
list.  Have you run this by them to see if this limits any use cases
out of the box?


I have.  I think they're okay with it.  
Anyone knows if these implementations-in-the-making are to be admired as 
open source somewhere on-line?


--
Marco



signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : The TACACS+ Protocol
Authors : Thorsten Dahm
  Andrej Ota
  Douglas C. Medway Gash
  David Carrel
  Lol Grant
Filename: draft-ietf-opsawg-tacacs-08.txt
Pages   : 43
Date: 2018-02-19

Abstract:
   TACACS+ provides Device Administration for routers, network access
   servers and other networked computing devices via one or more
   centralized servers.  This document describes the protocol that is
   used by TACACS+.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-08
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [OPSAWG] draft-ietf-opsawg-mud

[Joe Clarke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Speaking as a contributor...

On 2/19/18 05:03, Eliot Lear wrote:
> All,
> 
> Mark Nottingham and I had some extensive conversations about how
> to handle the MUD URL.  The issue is was that Mark identified a
> potential violation of a best practice in the way the URL was
> structured.  The principles I seek to maintain are these:
> 
> * The base MUD URL is formed solely by the Thing

_Formed by_, but relies on the URL pointing to something in the manuf.
world.  Meaning, the Thing doesn't just make this up, which is how it
initially read to me.

> * It may be necessary in the future for the MUD controller to
> provide additional information to the MUD file server. * How that
> happens can be decided in the future, but we should be conservative
> in our approach to leave options opened.

This sounds reasonable.

> 
> Therefore, the result of the discussions is that we should permit
> a normal HTTPS URI as a MUD URL, with all the associated semantics,
> with the exception that queries for now will not be allowed.
> 
> At the same time, as we build out future work, we will hold
> discussions with the Web/HTTP folk on the best way to proceed.
> There are at least two ways to tackle this in the future: an HTTP
> header, or some limited use of the query component.  We needn't
> decide any of that today.
> 
> Is this okay with you?

Yes.  It is good to be careful as to ensure a strong standard.  But...

Speaking as a co-chair...

Is this a case of perfect being the enemy of good?  I know of some
people working to implement this.  I don't think they are all on this
list.  Have you run this by them to see if this limits any use cases
out of the box?  It wouldn't make sense to put something out that
wouldn't be implemented (i.e., implementors all need that future work
to happen first).

Joe
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWortkAAKCRBvaI+K/hTP
h8ykAJ4+CF5Cd/P2UnN/OQWrytRf5+RIPACeNdsILVnCoyKwsAIWYX8pMOrs2pI=
=Swex
-END PGP SIGNATURE-

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

[OPSAWG] draft-ietf-opsawg-mud

[Eliot Lear]

All,

Mark Nottingham and I had some extensive conversations about how to
handle the MUD URL.  The issue is was that Mark identified a potential
violation of a best practice in the way the URL was structured.  The
principles I seek to maintain are these:

  * The base MUD URL is formed solely by the Thing
  * It may be necessary in the future for the MUD controller to provide
additional information to the MUD file server.
  * How that happens can be decided in the future, but we should be
conservative in our approach to leave options opened.

Therefore, the result of the discussions is that we should permit a
normal HTTPS URI as a MUD URL, with all the associated semantics, with
the exception that queries for now will not be allowed.

At the same time, as we build out future work, we will hold discussions
with the Web/HTTP folk on the best way to proceed.  There are at least
two ways to tackle this in the future: an HTTP header, or some limited
use of the query component.  We needn't decide any of that today.

Is this okay with you?

Eliot



signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg