Subject: protocol progress (again!)

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 May 2002 17:44:15 +0100

Folks,

This is the third time Magnus and I have asked about this,
without getting a clear concensus as to the WG position. 

This time, there's a default that Magnus and I have already 
agreed we'll recommend to the ADs if we don't get clear 
concensus, (but we're not saying which it is just yet, to 
try encourage you to answer:-).

As you know, the position is that the timing of the progression 
of the SASL-SRP draft is now in question, as reflected in the 
last meeting minutes. Since we currently have a mandatory to
implement dependency on this, that leaves us with four options 
as I see it:

A. Do nothing at all - just wait and see what happens and don't
produce any new drafts until the SASL-SRP position is clarified
which will probably take at least months.

B. Quit. We wrap up the WG and allow the protocol draft to
expire, but progress a version of the framework draft to show
we once existed.

C. Change the protocol draft to use something we know won't get
stuck in the IESG for process reasons. Magnus made a specific 
suggestion for this previously that we'd have to finalise on 
the list in the event we get clear concensus on this option
(which we need to get to proceed with it).

D. Finish off the current protocol draft, keeping the use of
SASL-SRP, and let the IESG worry about the process issues, in 
the knowledge that they're really quite likely to either park 
the draft (option A) or push it back to us (resulting in option 
B or C).

Can you express your preference over the next few days? (Note:
In the absence of clear concensus on this emerging over the 
next week, Mangus and I will simply annouce our preferred option 
to the list and the ADs.)

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Marshall Rose <[email-masked]>
Date: Thu, 30 May 2002 11:31:14 -0700

> next week, Mangus and I will simply annouce our preferred option 

options C.

/mtr

---

From: Tom Wu <[email-masked]>
Date: Thu, 30 May 2002 11:56:02 -0700

> SASL-SRP, and let the IESG worry about the process issues, in 

option D.

Tom
-- 
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg?  Sounds Swedish..."

---

From: Al Arsenault <[email-masked]>
Date: Thu, 30 May 2002 15:03:36 -0400

I also support Option C.

        Al Arsenault

---

From: Menno Pieters <[email-masked]>
Date: Thu, 30 May 2002 21:22:08 +0200

>I also support Option C.

And so do I

Regards,

Menno Pieters

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 30 May 2002 14:31:11 -0500

Option C.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 31 May 2002 12:58:46 +0200

> (which we need to get to proceed with it).

C, using TLS + DIGEST-MD5.

Btw, I note that BEEP is subject to downgrade attacks, is this
something that we should be concerned about?  I could not find a
particular requirement that would fit that problem in RFC 3157, so
perhaps not.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 May 2002 11:59:26 +0100

Hi Simon,

Have you a pointer to the details of a beep downgrade attack?

Stephen.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 31 May 2002 05:33:55 -0600

> Have you a pointer to the details of a beep downgrade attack?

I suspect Simon was talking about man-in-the-middle removing strong SASL
mechanisms and/or TLS profile from the list advertised by the other
peer.

This is not specific for BEEP, all other protocols have the same issue
(LDAP, IMAP, POP3, ACAP, ...).

> > particular requirement that would fit that problem in RFC 3157, so

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 31 May 2002 14:33:59 +0200

From the security considerations of RFC 3080:

,----
|        1.  A man-in-the-middle may remove the security-related profiles
|            from the BEEP greeting or generate a negative reply to the
|            "ready" element of the TLS transport security profile.  A
|            BEEP peer may be configurable to refuse to proceed without an
|            acceptable level of privacy.
`----

I am sorry if I'm misinterpreting this.

I agree with Alex that the same problem exists in LDAP, IMAP etc, but
SACRED is a security protocol.  Since I couldn't find a requirement
for protecting against these attacks in SACRED, perhaps there is no
need to worry.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 May 2002 14:31:07 +0100

Ok. I think we do need to counter this and the way to do it is
to REQUIRE use of security services in the protocol document as 
is already done in section 2.3.1.

Stephen.