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
Dave,
2. The nomcom is independent of the IESG and the IAB. Hence,
consultation with either of them, for deciding how to resolve nomcom
problems, creates an inherent conflict of interest.
If that had happened, it would have been a CoI. As Leslie and I
already made clear, it didn't.
> 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
> > 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
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
Dave Crocker wrote:
2. The nomcom is independent of the IESG and the IAB. Hence,
consultation with either of them, for deciding how to resolve
nomcom problems, creates an inherent conflict of interest.
If that had happened, it would have been a CoI. As Leslie and I
already made clear, it d
> 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
I think that you are confusing the meaning of "to consult" with "to
decide".
No, Dave, you are confusing "IESG" and "IETF Chair", and "IAB" and
"IAB Chair." Leslie and I were copied; the IESG and IAB were not.
Brian
___
Ietf mailing list
Ietf@i
Brian E Carpenter wrote:
I think that you are confusing the meaning of "to consult" with "to
decide".
No, Dave, you are confusing "IESG" and "IETF Chair", and "IAB" and
"IAB Chair." Leslie and I were copied; the IESG and IAB were not.
Brian,
The phrase "distinction without a difference"
> 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
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
> > 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
> 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
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
15 matches
Mail list logo
