Subject: [lemonade] WGLC 2192 bis

From: "Eric Burger" <[email-masked]>
Date: Tue, 17 Apr 2007 15:07:58 -0700

http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.tx
t

Have at it.  There are already a bunch of editorial nits found - look
for content problems.

Thanks.

Work Group Last Call closes 1 May 2007.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 18 Apr 2007 04:13:35 +0200

[Eric Burger]:
>
>   http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.txt
>   
>   Have at it.  There are already a bunch of editorial nits found -
>   look for content problems.

sorry if I missed previous discussion, but I think it should say
something explicit about STARTTLS, ie., something like the client
SHOULD issue STARTTLS before authenticating if the server supports it.
this may require the examples to be reworked, since it essentially
means you *always* have to do CAPABILITY.  if this is unacceptable, I
think we need a syntax in the URL to make TLS required -- I don't feel
comfortable that messages may start getting sent unencrypted just
because a server upgrade added support for DIGESTMD5 in addition to
good old PLAIN...

on a similar note, should something be said about the special case
which is port 993?

an editorial comment, if I may: I found the ABNF grammar hard to
navigate.  if you look at e.g. RFC 2822, you'll see that Pete Resnick
started at the top (for each concept) and did a depth first expansion
of the elements.  there are some exceptions in there, but as a general
rule, that ordering is very easy to follow, IMHO.  this will probably
make it easier to keep the elements required by URLAUTH separate, too.

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Apr 2007 13:53:17 +0100

>make it easier to keep the elements required by URLAUTH separate, too.
Hi Kjetil,
I've received a similar comment from Zoltan and Ted, so I will look into 
improving this.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Apr 2007 14:03:37 +0100

Kjetil Torgrim Homme wrote:

>means you *always* have to do CAPABILITY.
>
Fair enough. Can you suggest specific text to be added?

>if this is unacceptable, I
I was thinking about adding such syntactic element myself. I would like 
to hear other opinions on this before proceeding.

>on a similar note, should something be said about the special case
No, this document doesn't describe imaps.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 19 Apr 2007 14:07:34 +0200

> Fair enough. Can you suggest specific text to be added?

after thinking a little more about it, I've concluded that anonymous
access doesn't need encryption since access is wide open anyway, so we
shouldn't encourage "wastefulness".  how about this?

after this paragrah:

        If no user name or authentication mechanism is supplied, the
        client must authenticate as anonymous to the server. [...]

new text:

        For non-anonymous accesses, the client SHOULD issue STARTTLS
        before authenticating if the server has the capability.  <<The
        client MAY issue STARTTLS even for anonymous access.>>

I'm not sure we need the clarification for anonymous access.  with the
above text, only Example 3 needs to add a CAPABILITY command.

> to hear other opinions on this before proceeding.

it seems awkward, and unnecessary with the above addition.  it is really
the responsibility of the server to provide sufficient protection for
the data it hands out, the client can't really enforce it.

> No, this document doesn't describe imaps.

ah, of course.
-- 
Kjetil T.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 19 Apr 2007 09:07:54 -0600

On Thu, 19 Apr 2007, Kjetil Torgrim Homme wrote:
...
> shouldn't encourage "wastefulness".  how about this?

While confidentiality may not be needed, integrity may be important. 
Negotiating TLS is the only way to get that for anonymous access.  Isn't 
integrity-only protection what the WITH_NULL cipher suites 
(TLS_RSA_WITH_NULL_SHA, TLS_RSA_WITH_NULL_MD5) are for?

(Mind you, there may be no server implementations that offer those suites 
without manual configuration, given that at least OpenSSL disables them by 
default...)

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Apr 2007 16:24:25 +0100

Kjetil Torgrim Homme wrote:

>shouldn't encourage "wastefulness".
>
Agreed.

>how about this?
This seems fine, but a client can also try SASL security layer, such as 
GSSAPI instead. In which case TLS would not be needed.
I need to think how to make your text more generic.

>it seems awkward, and unnecessary with the above addition.
>
There are different cases. If TLS "SHOULD be negotiated", then the 
addition above covers it.
If "TLS MUST be negotiated" (i.e. the data can't be retrieved unless 
connection confidentiality is achieved), then a new
syntactic element is needed. The server can enforce it if such syntactic 
element is signed with URLAUTH. The client would
know not to try accessing data if such element is present.

>it is really
Besides, imaps is a rathole I don't want to get into ;-)

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Apr 2007 16:37:35 +0100

Alexey Melnikov wrote:

> This seems fine, but a client can also try SASL security layer, such 
> as GSSAPI instead. In which case TLS would not be needed.

How about the following text:

   Clients wishing to achieve data confidentiality SHOULD use the STARTTLS
   command (if supported by the server) before starting authentication,
   or use a SASL mechanism, such as GSSAPI, that provides a confidentiality
   security layer.

Should this text be moved to Security Considerations section?

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 25 Apr 2007 14:57:01 +0200

>    or use a SASL mechanism, such as GSSAPI, that provides a confidentiality

sounds good!  perhaps mention integrity as well as confidentiality, as
per Philip's comment?

> Should this text be moved to Security Considerations section?

I guess you need to mention this issue in the Security Considerations
*anyway*, so I think it suffices to put it there.  when I looked for
guidance in the draft, I did a fulltext search for "TLS" and "crypt", so
I would find it anyway, and of course everyone should do as I ;-)

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Apr 2007 14:45:21 +0100

>sounds good!  perhaps mention integrity as well as confidentiality, as
Done.

>I would find it anyway, and of course everyone should do as I ;-)
Ok, the suggested text was moved to section 10.