Great! Let's do that!
On Thu, Feb 18, 2016 at 12:28 AM, <ietf-request@xxxxxxxx> wrote:
Send ietf mailing list submissions to
ietf@xxxxxxxx
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
ietf-request@xxxxxxxx
You can reach the person managing the list at
ietf-owner@xxxxxxxx
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: ???? <jinmei@xxxxxxxxxx>
To: Christian Huitema <huitema@xxxxxxxxxxx>
Cc: draft-ietf-dhc-anonymity-profile@xxxxxxxx, dhc-chairs@xxxxxxxx,
ietf@xxxxxxxx, IETF-Announce <ietf-announce@xxxxxxxx>,
"dhcwg@xxxxxxxx" <dhcwg@xxxxxxxx>
Subject: Re: [dhcwg] Last Call:
<draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP
clients) to Proposed Standard
Message-ID:
<CAJE_bqcnr78u3wnzzf4pj4Sqqs9=o17eVBw_-wa00FefFTVQuA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8
At Tue, 16 Feb 2016 10:13:49 -0800,
"Christian Huitema" <huitema@xxxxxxxxxxx> 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 <ajs@xxxxxxxxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: draft-klensin-iaoc-member-01 (was: Re: I-D Action:
draft-hardie-iaoc-iab-update-00.txt)
Message-ID: <20160218025414.GM66257@xxxxxxxxxxxxxxx>
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
ajs@xxxxxxxxxxxxxxxxxx
------------------------------
Message: 3
Date: Wed, 17 Feb 2016 22:24:42 -0500 (EST)
From: Paul Wouters <paul@xxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <alpine.LFD.2.20.1602172221020.27439@xxxxxxxxxxxxxx>
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 <ietf-dane@xxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <19DDAD6C-B997-48C3-83E5-A61E27D97B6A@xxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
> On Feb 17, 2016, at 10:24 PM, Paul Wouters <paul@xxxxxxxxx> 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 <mstjohns@xxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: draft-klensin-iaoc-member-01 (was: Re: I-D Action:
draft-hardie-iaoc-iab-update-00.txt)
Message-ID: <56C556A5.8090202@xxxxxxxxxxx>
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 <jari.arkko@xxxxxxxxx>
To: Russ Housley <housley@xxxxxxxxxxxx>
Cc: draft-ietf-eppext-tmch-smd.all@xxxxxxxx, IETF Gen-ART
<gen-art@xxxxxxxx>, IETF <ietf@xxxxxxxx>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-04
Message-ID: <20EB4776-9221-4732-95D0-A666E6C9903B@xxxxxxxxx>
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 <housley@xxxxxxxxxxxx> 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
> Gen-art@xxxxxxxx
> 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 <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: Is Fragmentation at IP layer even needed ?
Message-ID: <56C5808C.1090906@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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
ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
------------------------------
End of ietf Digest, Vol 93, Issue 75
************************************