Re: [perpass] "Its an attack" BCP draft

[Ralf Skyper Kaiser <[e-mail]>]

Hi,

"...pervasive monitoring significantly more expensive or infeasible"

Recommend to remove 'significantly'. (otherwise there will be an argument
what 'significant' means. 1M USD? 10M USD? And how expensive is it anyway
to send a RST to 240M users? 1 cent? 1 Dollar?).

"...pervasive monitoring" means very widespread privacy-invasive gathering
of protocol"

Recommend to remove 'very' and 'privacy-invasive'. "Pervasive monitoring
means widespread gathering of protocol ...".

RFC1984 had more detail and these specifics in RFC1984 were helpful.  Some
specifics for this I-D:
ENCRYPT EVERYTHING
SECURITY BY DEFAULT
....please add?...

I-D does not touch regulatory changes (liability of service providers
towards its users and neglect when failing to support HTTPS for example).
Wish it did. (One reason why the internet is not secure is because the
manufactures get away shipping products that have all security features
disabled by default...or with default 0000 pins). (RFC1984 did mention
regulatory problems [export control] for example).

Rest is awesome!

regards,

Ralf




On Wed, Nov 20, 2013 at 10:16 PM, Stephen Farrell <[e-mail]
> wrote:

>
> Hi all,
>
> Following up on item 3a from the status/plan mail [1] I sent
> last week, Hannes and myself have written up an I-D [2] that
> tries to capture the consensus in the room from the Vancouver
> tech plenary and we're proposing as a BCP.
>
> We're deliberately trying to keep this short and sweet and to
> not (yet) go beyond what was the gist of the hums - we think
> progressing e.g. the threat model or the privacy BCP or other
> bits of related work is liable to take longer and there's value
> in documenting that the IETF as a whole has consensus on the
> most significant bit first so those and other bits of work
> don't all have to re-establish that as they are processed.
> Hopefully we can all easily agree that that's a useful target
> and focus comments on whether on not we've expressed that
> consensus well or not.
>
> <boring-bit>
> We've been bouncing versions of this around amongst the IESG
> and IAB for the last week, and process-wise, that has been
> fun already. As you'll see from section 3 of the draft, we can
> no longer just shoot out an RFC agreed by the IESG and IAB so
> the plan for this is that when Hannes and I figure this looks
> ready, based on your comments, then we'll ask Jari to start a
> 4-week IETF LC for it. When he thinks that's ok he'll start it
> and then we'll see how that goes. Assuming that goes well, then
> sometime during IESG evaluation the IAB will decide if they
> like the final text (or not, which'd be "interesting") and if
> they do then an IAB note saying "yep, we like it" will be added
> sometime during/after IESG evaluation before this goes to the
> RFC editor. In an ideal world, you'll all love the -00 already
> and tell us that and we'll be done with all of the above super
> duper process stuff by the end of the year. (Haven't we built
> ourselves a lovely crazy process? ;-)
>
> I really hope we don't end up with a process debate over this,
> since the above, silly and all as it is, should achieve the
> desirable outcome which is a simple BCP, approved by the IESG
> after an IETF LC and also supported by the IAB. The value in
> that is that it seems to be as close as we can get to the same
> setup as RFCs 1984 and 2804 which is the right kind of heritage
> for this one. So there is a reasonably good reason for the
> process-crap.
> </boring-bit>
>
> Anyway, ignoring process, comments on this are welcome, so
> please take a read of the two pages of content and let us know
> what you think. If you do think its already good enough for
> starting an IETF last call, then saying that is useful as well.
>
> And since the IETF LC will happen on the [e-mail] list,
> using this list for initial processing should be fine.
>
> Cheers,
> S.
>
> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html
> [2] http://tools.ietf.org/html/draft-farrell-perpass-attack
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass
>