Jeffrey Hutzelman wrote:
On Tuesday, September 12, 2006 06:06:08 PM -0400 John C Klensin
<[EMAIL PROTECTED]> wrote:
You are correct. I did not address that issue, partially
because, personally, I do not consider it very important. While
documenting what we are doing would be nice, I don't
Steve,
> The IAB spends -- or spent; I haven't been on the IAB since 2000 -- an
> amazing percentage of its time on layer 9 issues. Most IAB members dislike
> that (and some ignore that part), but much of it seemed to be stuff that
> the IETF had to do. I suppose we could ask the Nomcom to select
On Tuesday, September 12, 2006 06:06:08 PM -0400 John C Klensin
<[EMAIL PROTECTED]> wrote:
You are correct. I did not address that issue, partially
because, personally, I do not consider it very important. While
documenting what we are doing would be nice, I don't believe the
community is
--On Tuesday, 12 September, 2006 13:26 -0700 "Hallam-Baker,
Phillip" <[EMAIL PROTECTED]> wrote:
> John,
>
> While I agree that the IESG unlikely to change how it behaves
> I still don't think you have explained why it should resist
> changing the process so that it describes how it behaves in
>
On Tue, 12 Sep 2006 22:24:50 +0200, Eliot Lear <[EMAIL PROTECTED]> wrote:
> John C Klensin wrote:
> > Eliot,
> >
> > The discussion of the question you asked here seems to have been
> > immediately sidetracked. I, at least, believe the original question
> > is worth some community discussion and
L PROTECTED]
> Sent: Tuesday, September 12, 2006 2:51 PM
> To: Eliot Lear
> Cc: IETF Discussion
> Subject: Re: what happened to newtrk?
>
> Eliot,
>
> The discussion of the question you asked here seems to have
> been immediately sidetracked. I, at least, believe
John C Klensin wrote:
> Eliot,
>
> The discussion of the question you asked here seems to have been
> immediately sidetracked. I, at least, believe the original question
> is worth some community discussion and possibly a conclusion. More
> below.
Thank you, John. You've caught the jist of my c
Eliot,
The discussion of the question you asked here seems to have been
immediately sidetracked. I, at least, believe the original
question is worth some community discussion and possibly a
conclusion. More below.
--On Tuesday, September 05, 2006 4:39 PM +0200 Eliot Lear
<[EMAIL PROTECTED
John C Klensin wrote:
[skipping many good points]
> I am very much in favor of high specification quality.
[...]
> we should aspire to specifications that are absolutely clear
> about their strengths and weaknesses _especially_ where
> security and basic network operations (e.g., scalability) are
--On Friday, 08 September, 2006 22:09 -0700 "C. M. Heard"
<[EMAIL PROTECTED]> wrote:
> On Fri, 8 Sep 2006, John C Klensin wrote:
>> --On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman
>> wrote:
>> > OK. I read RFC 2026 as giving the IESG the latitude to
>> > make a judgment of the technic
On Fri, 8 Sep 2006, John C Klensin wrote:
> --On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman wrote:
> > OK. I read RFC 2026 as giving the IESG the latitude to make a
> > judgment of the technical quality of a protocol (and the TS)
> > when advancing along the standards track. I'd always
> From: Ned Freed [mailto:[EMAIL PROTECTED]
> Indeed, although I have to say that in my experience DNSSEC
> deployments are rare. I wish it were otherwise but that's
> been my observation. As you have pointed out elsewhere, the
> necessary impetus to deploy doesn't seem to exist.
I doubt that
> > From: Ned Freed [mailto:[EMAIL PROTECTED]
> > > The attacker cannot downgrade the server security,
> > particularly if the
> > > server does not support unencrypted IMAP or POP.
> >
> > I don't think the lack of support for unencrypted IMAP or POP
> > is quite sufficient. What's to stop an at
Christian Huitema wrote:
> yes, DIGEST-MD5 has essentially the same issue.
If the SASL folks want their very own "decruft" experiment
they'd have to update RFCs 2244, 2645, 3013 (a BCP), check
ESMTPA in 3848, do something about 2617, and probably some
more RFCs.
DIGEST-MD5 and OTP are regist
> Next slide, yes, CRAM-MD5 is *not* designed for that attack.
That is my point. We should not, in 2006, standardize "security" methods
that are not robust against a fairly well known attack.
> Adding a prose version of your slides 3..6 and 13 to the
> security considerations of a 2195bis could i
--On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:
>> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
>
> John> Actually, that topic opens up one of the fundamental
> issues John> with our standards process ... one where
> better definition
> From: Ned Freed [mailto:[EMAIL PROTECTED]
> > The attacker cannot downgrade the server security,
> particularly if the
> > server does not support unencrypted IMAP or POP.
>
> I don't think the lack of support for unencrypted IMAP or POP
> is quite sufficient. What's to stop an attacker ac
On Fri, 8 Sep 2006, Ned Freed wrote:
> I don't think the lack of support for unencrypted IMAP or POP is quite
> sufficient. What's to stop an attacker acting as a MITM (by
> publishing a bogus SRV record or whatever) getting an unencypted connection
> and
> turning around and connecting to the se
> > From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
> >
> > On Thursday, September 07, 2006 08:12:44 PM -0700
> > "Hallam-Baker, Phillip"
> > <[EMAIL PROTECTED]> wrote:
> >
> > > The solution to this particular problem is to use SSL as the transport.
> > > IMAP and POP both support this use. It
> From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
>
> On Thursday, September 07, 2006 08:12:44 PM -0700
> "Hallam-Baker, Phillip"
> <[EMAIL PROTECTED]> wrote:
>
> > The solution to this particular problem is to use SSL as
> the transport.
> > IMAP and POP both support this use. It is a tr
Christian Huitema wrote:
> http://www.huitema.net/talks/ietf63-security.ppt
Thanks, with that hint I finally found the HTML version:
http://www3.ietf.org/proceedings/05aug/slides/apparea-4/ and
http://www3.ietf.org/proceedings/05aug/slides/plenaryt-1.pdf
>> With a somewhat unusual password I wou
I've given up
to report it, the complete issue is too ridiculous, one user
ietf password ietf can't get read access anymore, nobody
knows why, [EMAIL PROTECTED]
> If we're talking about what happened to newtrk or what
> the standards process should be, then we're talking about
> -Original Message-
> From: Frank Ellermann [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 07, 2006 7:49 PM
> To: ietf@ietf.org
> Subject: Re: RFC 2195 (Was: what happened to newtrk?)
>
> Christian Huitema wrote:
>
> > both Steve Bellovin and I
On Thursday, September 07, 2006 08:12:44 PM -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
The solution to this particular problem is to use SSL as the transport.
IMAP and POP both support this use. It is a trivial matter to discover
that IMAPS is supported using an SRV record.
O
ased on
my experiences with people not bothering to report problems to me and then
complaining that they never got fixed).
In addition, while I mostly agree that documenting a protocol is usually
better than not documenting it, I fail to see the relevance of that point
in this discussion.
> From: Christian Huitema [mailto:[EMAIL PROTECTED]
> > From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] At 04:07 PM
> > 9/7/2006, John C Klensin wrote:
> > >I think we have a small misunderstanding here. Let me say more
> > >clearly and briefly
> >
> > My message was intended to clarify why
Christian Huitema wrote:
> both Steve Bellovin and I presented the issues with such
> techniques.
Is that presentation online available somewhere ? I find the
way to http://www3.ietf.org/proceedings/05aug/index.html but
then I'm lost.
> Basic challenge response mechanisms like CRAM-MD5 are simp
Jeffrey Hutzelman wrote:
> Multiple interoperable implementations is not the
[only]
> criteria for advancement; it is necessary but not
> sufficient
2026 says "mature, useful, well-understood, stable."
A downref to SASLprep for a 2195bis DS would be odd,
in that case better publish 2195bis as PS
> From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED]
> At 04:07 PM 9/7/2006, John C Klensin wrote:
> >I think we have a small misunderstanding here. Let me say more
> >clearly and briefly
>
> My message was intended to clarify why the SASL WG is
> pursuing an Informational recommendation for its RF
At 04:07 PM 9/7/2006, John C Klensin wrote:
>I think we have a small misunderstanding here. Let me say more
>clearly and briefly
My message was intended to clarify why the SASL WG is
pursuing an Informational recommendation for its RFC2195bis
work and to redirect any comments specific to this wo
> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
John> Actually, that topic opens up one of the fundamental issues
John> with our standards process ... one where better definition
John> and clear community consensus is, IMO, needed. Measured by
John> our documented crite
On Thursday, September 07, 2006 07:48:45 PM -0400 Jeffrey Hutzelman
<[EMAIL PROTECTED]> wrote:
Well, he could ask that 2195 be advanced as-is, but I would expect such
an effort to fail, as that version has turned out to be somewhat
underspecified. Multiple interoperable implementations is n
On Thursday, September 07, 2006 07:07:51 PM -0400 John C Klensin
<[EMAIL PROTECTED]> wrote:
However, 2195 is not, itself, a SASL method and there is nothing
in the procedural rules as I understand them that permits the
SASL WG to de-standardize it (you could write any of several
styles of do
--On Thursday, 07 September, 2006 14:31 -0700 "Kurt D. Zeilenga"
<[EMAIL PROTECTED]> wrote:
> At 01:36 PM 9/7/2006, John C Klensin wrote:
>> Actually, that topic opens up one of the fundamental issues
>> with our standards process ... one where better definition
>> and clear community consensus
John C Klensin wrote:
> that topic opens up one of the fundamental issues with our
> standards process ... one where better definition and clear
> community consensus is, IMO, needed.
"Fundamental" and "consensus" sounds dangerous, see subject.
> 2195 exists in multiple independent implementati
At 01:36 PM 9/7/2006, John C Klensin wrote:
>Actually, that topic opens up one of the fundamental issues with
>our standards process ... one where better definition and clear
>community consensus is, IMO, needed. Measured by our documented
>criteria, 2195 exists in multiple independent implementat
--On Wednesday, 06 September, 2006 13:35 +0200 Frank Ellermann
<[EMAIL PROTECTED]> wrote:
> Brian E Carpenter wrote:
>
>> 3464 is already DS according to the RFC Index.
>
> Good, the process works, unlike my memory: I meant 3834,
> a few days ago I wrote 3864 instead of 3834 on another
> list
Brian E Carpenter wrote:
> 3464 is already DS according to the RFC Index.
Good, the process works, unlike my memory: I meant 3834,
a few days ago I wrote 3864 instead of 3834 on another
list, so that's the third attempt: 3834.
[interoperability report]
> if {all mandatory and optional features
Brian E Carpenter wrote:
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report,
SASL WG is revision it (draft-ietf-sasl-crammd5-07.txt).
And no, this document is
C. M. Heard wrote:
> Having just re-read the charter, I would have to say so. I think we
> would have been better served if the WG had been given the much less
> ambitious task of producing an update of RFC 2026 that describes what
> we actually do.
>
What we actually do is a one step process.
DS first.
Best regards,
Pasi
-Original Message-
From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: 06 September, 2006 12:57
To: Frank Ellermann
Cc: ietf@ietf.org
Subject: Re: what happened to newtrk?
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exac
an extension to IMAP), you'd probably need to bring
IMAP to DS first.
Best regards,
Pasi
> -Original Message-
> From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]
> Sent: 06 September, 2006 12:57
> To: Frank Ellermann
> Cc: ietf@ietf.org
> Subject: Re: what happened to
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report, and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify R
Eliot Lear wrote:
> few if any specifications get to draft or full standard,
> and no review of PS had ever been done along the timelines
> specified in RFC 2026.
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
> Numerous proposals were made within the working g
On Tue, 5 Sep 2006, Eliot Lear wrote:
> Numerous proposals were made within the working group. The ISD proposal
> seemed to be the one that had the most support. However, this proposal
> ran into stiff opposition within the IESG and was effectively killed.
> We can argue until the cows come home
scussion"
Sent: Tuesday, September 05, 2006 9:33 AM
Subject: Re: what happened to newtrk?
Eliot - the problem quite simply is that the IESG needs to be disbanded.
It
serves no other purpose than to complicate the creation and acceptable
vetting models for Internet Standards and as such really
t;Eliot Lear" <[EMAIL PROTECTED]>; "IETF Discussion"
Sent: Tuesday, September 05, 2006 9:33 AM
Subject: Re: what happened to newtrk?
> > Eliot - the problem quite simply is that the IESG needs to be disbanded.
It
> > serves no other purpose than to complicate the creation
Eliot - the problem quite simply is that the IESG needs to be disbanded. It
serves no other purpose than to complicate the creation and acceptable
vetting models for Internet Standards and as such really needs to be a thing
of the past - The standards process is easily updated to remove the IESG
t; <[EMAIL PROTECTED]>
To: "IETF Discussion"
Sent: Tuesday, September 05, 2006 7:39 AM
Subject: what happened to newtrk?
> All,
>
> As a participant in the newtrk working group and someone who actually
> ran one of the only reasonably successful experiments in that gr
All,
As a participant in the newtrk working group and someone who actually
ran one of the only reasonably successful experiments in that group, I
think the community is owed a better accounting of why WG failed, and
that steps should be taken to see that such efforts do not fail in the
future. Th
50 matches
Mail list logo
