Re: ietf Digest, Vol 93, Issue 75

[Zack Cylinder <[e-mail]>]

Great! Let's do that!

Zack Cylinder
Cloud Training Specialist
Cloudbakers.com


On Thu, Feb 18, 2016 at 12:28 AM, <[e-mail]> wrote:

> Send ietf mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ietf digest..."
>
>
> Today's Topics:
>
>    1. Re: [dhcwg] Last Call:
>       <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for
>       DHCP clients) to Proposed Standard (????)
>    2. Re: draft-klensin-iaoc-member-01 (was: Re: I-D Action:
>       draft-hardie-iaoc-iab-update-00.txt) (Andrew Sullivan)
>    3. Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> (Paul Wouters)
>    4. Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
>       (Viktor Dukhovni)
>    5. Re: draft-klensin-iaoc-member-01 (was: Re: I-D Action:
>       draft-hardie-iaoc-iab-update-00.txt) (Michael StJohns)
>    6. Re: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-04
>       (Jari Arkko)
>    7. Re: Is Fragmentation at IP layer even needed ? (Masataka Ohta)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 16 Feb 2016 10:25:57 -0800
> From: ???? <[e-mail]>
> To: Christian Huitema <[e-mail]>
> Cc: [e-mail], [e-mail],
>         [e-mail], IETF-Announce <[e-mail]>,
>         "[e-mail]" <[e-mail]>
> Subject: Re: [dhcwg] Last Call:
>         <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for
> DHCP
>         clients) to Proposed Standard
> Message-ID:
>         <CAJE_bqcnr78u3wnzzf4pj4Sqqs9=
> [e-mail]>
> Content-Type: text/plain; charset=UTF-8
>
> At Tue, 16 Feb 2016 10:13:49 -0800,
> "Christian Huitema" <[e-mail]> wrote:
>
> > > I'm not sure what Brian tried to indicate in his message, but at least
> this
> > > section looks vague to me about the rationale for the "SHOULD NOT".
> It's
> > > not obvious to me how IA_PD is worse than IA_NA in terms of privacy.
> Is this
> > > a "SHOULD NOT" simply because the "interaction"
> > > (is not yet fully understood and) requires further study?
> >
> > This section was rewritten in draft-07, following the feedback received
> during IETF last call. Basically, we stopped being lazy and actually did
> the study. And took a lot of the text that Lorenzo provided.
>
> I didn't intend to make my comment as a blocking issue for the last
> call, but just to be clear: The revised section 4.5.2 of rev 07 looks
> good to me.
>
> --
> JINMEI, Tatuya
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 17 Feb 2016 21:54:14 -0500
> From: Andrew Sullivan <[e-mail]>
> To: [e-mail]
> Subject: Re: draft-klensin-iaoc-member-01 (was: Re: I-D Action:
>         draft-hardie-iaoc-iab-update-00.txt)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> On Mon, Feb 15, 2016 at 09:53:22PM -0500, Michael StJohns wrote:
> > The term lengths for the IAB and IESG would be variable to allow
> different
> > "entering classes" to serve on the IAOC. A member would expected to
> serve at
> > least two years and would be automatically reappointed to the IAOC for an
> > additional year if they are re-upped to the IAB or IESG  and have served
> > less than two years.
>
> I have nothing to say about the IESG case here, but why this rule for
> the IAB?  This is a new invention, because the IAB chair's _ex
> officio_ position on the IAOC comes by virtue of being IAB chair, and
> that appointment is for no more than one year-cycle (i.e. Spring
> meeting to Spring meeting -- this year it'll turn out slightly longer
> than one year).  For all I know, the IAB will replace me in April with
> someone else.  (Indeed, some days I think that, were they sane, they'd
> replace me that afternoon!  That'd be less than a year.)
>
> > replacements.  But, if you change the model, then you have to figure out
> how
> > to give the IAOC *at least* the same level of stability that it currently
> > has in membership terms.
>
> But you're making it greater than it is now.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> [e-mail]
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 17 Feb 2016 22:24:42 -0500 (EST)
> From: Paul Wouters <[e-mail]>
> To: [e-mail]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On Tue, 16 Feb 2016, John Levine wrote:
>
> >>>>      https://tools.ietf.org/html/draft-moore-email-addrquery-01
> >
> >> Unfortunately, the draft is useless for end-to-end encryption, as it
> >> relies on a clean path from the client to the recipient's SMTP server
> ...
> >
> > I would encourage anyone interested in this topic to read the draft,
> > particularly section 4.  No, it does not depend on a clean path from
> > the MUA to the recipient MTA.
>
>     This section defines a service extension to the Mail Submission
>     Protocol [RFC6409] which can be used by an authenticated, authorized
>     client to query an SMTP server on port 25 for information about an
>     email address.  This is intended only as a workaround for port 25
>     blocking, so the extension is minimally tailored for that purpose.
>
> So if my ISP is blocking port 25, I am forced to ask my ISP if the
> remote party could accept encrypted email and to which key?
>
> It is not "end to end" encryption, if the ISP can change the outcome.
>
> So again, the above draft does not provide a workable solution for
> the openpgpkey draft.
>
> Paul
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 17 Feb 2016 22:38:08 -0500
> From: Viktor Dukhovni <[e-mail]>
> To: [e-mail]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
>
>
> > On Feb 17, 2016, at 10:24 PM, Paul Wouters <[e-mail]> wrote:
> >
> > So if my ISP is blocking port 25, I am forced to ask my ISP if the
> > remote party could accept encrypted email and to which key?
>
> [ That's only if your ISP is your submission server, in which case
> they're also likely operating the zone that would public your
> public keys, and you're likely vulnerable to a variety of attacks
> via that ISP.  Since faking the keys of remote parties is likely
> tamper-evident, and such faking can also happen by who-ever is
> publishing the zone data on the other end, I think this is a
> reasonable architecture, but we digress... ]
>
> The addrquery draft is not under discussion here, so perhaps I
> should not even have said that much.  Exploring additional
> approaches seems reasonable.
>
> --
>         Viktor.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 18 Feb 2016 00:29:09 -0500
> From: Michael StJohns <[e-mail]>
> To: [e-mail]
> Subject: Re: draft-klensin-iaoc-member-01 (was: Re: I-D Action:
>         draft-hardie-iaoc-iab-update-00.txt)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 2/17/2016 9:54 PM, Andrew Sullivan wrote:
> > Hi,
> >
> > On Mon, Feb 15, 2016 at 09:53:22PM -0500, Michael StJohns wrote:
> >> The term lengths for the IAB and IESG would be variable to allow
> different
> >> "entering classes" to serve on the IAOC. A member would expected to
> serve at
> >> least two years and would be automatically reappointed to the IAOC for
> an
> >> additional year if they are re-upped to the IAB or IESG  and have served
> >> less than two years.
> > I have nothing to say about the IESG case here, but why this rule for
> > the IAB?  This is a new invention, because the IAB chair's _ex
> > officio_ position on the IAOC comes by virtue of being IAB chair, and
> > that appointment is for no more than one year-cycle (i.e. Spring
> > meeting to Spring meeting -- this year it'll turn out slightly longer
> > than one year).  For all I know, the IAB will replace me in April with
> > someone else.  (Indeed, some days I think that, were they sane, they'd
> > replace me that afternoon!  That'd be less than a year.)
>
> There's what's written down and then there's what actually happens.
> According to the IAB history page, no IAB chair so far has served less
> than 2 years as chair so I'm not all that worried about your scenario.
> And there's a lot of pressure to have some stability in the IAB chair's
> position, which translates into similar stability in the IAOC IAB
> position.  If you want to change who serves on the IAOC from the IAB,
> then we need to have a rule with respect to that appointment that gives
> us a similar result to what's already been happening.   E.g. someone
> from the IAB on the IAOC who will be around for ideally for a few years.
>
> >
> >> replacements.  But, if you change the model, then you have to figure
> out how
> >> to give the IAOC *at least* the same level of stability that it
> currently
> >> has in membership terms.
> > But you're making it greater than it is now.
>
> You make that sound like its a bad thing?
>
> Seriously though, as I noted above, I'm not really making it greater -
> I'm just trying to come up with an approach that preserves the current
> *actual* stability.
>
> Later, Mike
>
> >
> > Best regards,
> >
> > A
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 18 Feb 2016 10:18:33 +0200
> From: Jari Arkko <[e-mail]>
> To: Russ Housley <[e-mail]>
> Cc: [e-mail], IETF Gen-ART
>         <[e-mail]>, IETF <[e-mail]>
> Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-04
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="windows-1252"
>
> Many thanks for your reviews, Russ.
>
> I have looked at the document as well, looked up the reference, and agree
> with Russ? comment that there is something missing. I would have wanted to
> talk about this issue wrt this document on tonight?s IESG telechat, but
> Stephen Farrell has already raised this point. I am interested in the
> matter being resolved, however.
>
> Also, Gustavo, did you get a chance to look at Russ? editorial comments?
> Those seem worthwhile to be addressed as well.
>
> Thanks,
>
> Jari
>
> On 12 Feb 2016, at 18:57, Russ Housley <[e-mail]> wrote:
>
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair. Please wait for direction from your
> > document shepherd or AD before posting a new version of the draft.
> >
> > For more information, please see the FAQ at
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-eppext-tmch-smd-04
> > Reviewer: Russ Housley
> > Review Date: 2016-02-12
> > IETF LC End Date: 2015-12-04
> > IESG Telechat date: 2016-02-18
> >
> > Summary:  Not Ready
> >
> >
> > Major Concerns:
> >
> >
> > The Security Considerations include this paragraph:
> >
> >   Signed Marks are used primarily for sunrise domain name registrations
> >   in gTLDs, but other third-parties might be using them.  A party using
> >   Signed Marks should verify that the digital signature is valid based
> >   on local policy.  In the case of gTLDs, the RPM Requirements document
> >   [ICANN-TMCH] defines such policy.
> >
> > The RPM Requirements document [ICANN-TMCH] does not seem to say anything
> > at all about validating a digital signature.
> >
> > Protocols that make use of certificates perform some checks on the
> > certificate subject name to ensure that it represents an appropriate
> > signer.  That is missing from this document, and it is not contained in
> > [ICANN-TMCH] either.
> >
> >
> > Minor Concerns:
> >
> > Section 2, second paragraph, I think that use of the phrase "in the
> > appropriate objects" ass ambiguity.  I suggest:
> >
> >   This section defines some elements as OPTIONAL.  If an elements is
> >   not defined as OPTIONAL, then it MUST be included in the object.
> >
> > The NOTE at the end of Section 2.3 about choosing an algorithm other
> > that RSA-SHA256 is better suited for the Security Considerations.
> > It would be helpful to say something more about the needed security
> > strength.
> >
> > Why is RFC5730 a normative reference?  I do not see a dependency.
> >
> >
> > Other Editorial Comments:
> >
> > Section 1: s/nothing precudle/nothing precludes/
> >
> > _______________________________________________
> > Gen-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/gen-art
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 842 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> https://mailarchive.ietf.org/arch/browse/ietf/attachments/20160218/8ad52c31/attachment.asc
> >
>
> ------------------------------
>
> Message: 7
> Date: Thu, 18 Feb 2016 17:27:56 +0900
> From: Masataka Ohta <[e-mail]>
> To: [e-mail]
> Subject: Re: Is Fragmentation at IP layer even needed ?
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=iso-2022-jp
>
> Masataka Ohta (I) wrote:
>
> > The RFC is a complete mess, in various ways. It says flow IDs are
> > good because it is random, but, at the same time, it says flow
> > IDs may not be random.
>
> I found the rfc is even worse.
>
> The most important thing the rfc must have stated (it
> does not, of course) is:
>
>         (SRC1, DST1, flow_ID1)
>
> of a stateful flow MUST be unique (not used by packets
> not belonging to the flow) within the Internet,
> which can be guaranteed only by an end (source or
> destination), which is a straight forward manifestation
> of the end to end argument.
>
> But, the rfc allow routers (firewalls) change flow IDs to
> nonzero value.
>
> So, if a router changes flow ID of (SRC1, DST1, flow_ID2),
> from flow_ID2 to flow_ID3, then, there is a possibility
> that flow_ID1==flow_ID3, which is fatal for the stateful
> flow, if the modified packets are merged to the stateful
> flow (certain protection against merging possible but
> not robust against route changes).
>
> Of course, section 6.1 of the rfc on covert channels is
> abstract nonsense, because covert channels may be created
> in various ways to carry information, for example, with
> extension headers (fragmentation boundaries, for example,
> can be arbitrary), which means firewalls should reject
> packets with extension headers.
>
>                                         Masataka Ohta
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
> ------------------------------
>
> End of ietf Digest, Vol 93, Issue 75
> ************************************
>