Subject: [kitten] AD review of draft-ietf-kitten-digest-to-historic-03

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Mar 2011 17:33:42 +0100

This looks fine to me. Pretty comprehensive.

One nit, two questions.

1. I'd get rid of the note after the abstract, but leaving
it there is fine.

2. Why only pick DIGEST-MD5 and not e.g PLAIN as well?
(I'm not complaining, any reasonable answer I can pass
on if asked will be fine I think.)

3. Do you know if there are any uses of this mechanism
that'd be badly affected by obsoleting this, and where
new code is likely to be written/deployed? (As for
point 2 above. Just saying "not that we know" is fine
here.)

There's no need for loads of responses, e.g. the shepherd
could just answer giving folks a chance to disagree.

Thanks,
S.

PS: This is my 1st doc to handle as AD. Apologies in
advance if I muck up the process:-)

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 Mar 2011 18:41:56 +0200

>1. I'd get rid of the note after the abstract, but leaving
Ok. Can I do this after IETF LC?

>on if asked will be fine I think.)
Because PLAIN is actually more interoperable ;-)?

>point 2 above. Just saying "not that we know" is fine
Not that I know. I think there are enough SCRAM implementations now, so 
I expect more SCRAM implementations than DIGEST-MD5 to be written in the 
future.

>advance if I muck up the process:-)
You are doing fine so far. Have no doubts: I will tell you if you do 
something wrong ;-).

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Mar 2011 13:14:22 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> 3. Do you know if there are any uses of this mechanism
    Stephen> that'd be badly affected by obsoleting this, and where new
    Stephen> code is likely to be written/deployed? (As for point 2
    Stephen> above. Just saying "not that we know" is fine here.)

    Stephen> There's no need for loads of responses, e.g. the shepherd
    Stephen> could just answer giving folks a chance to disagree.

    Stephen> Thanks, S.

    Stephen> PS: This is my 1st doc to handle as AD. Apologies in
    Stephen> advance if I muck up the process:-)

    Stephen> _______________________________________________ Kitten
    Stephen> mailing list [email-masked]
    Stephen> https://www.ietf.org/mailman/listinfo/kitten

The pattern of plain+TLS is secure under the assumption that yo,u are
talking to the right server and that server is adequately trusted.
This pattern is very common on the web and for similar reasons in other
application protocols.
(sasl plain is not used on the web, but it would be silly to get rid of
this pattern from say IMAP before we do with http)

Consider for example what a server can do if its password store is
backed by some hash function like the unix crypt() call.
In such a case, where there is no challenge/response protocol
standardized with the right hash function, you're kind of stuck with
plain.
This happens quite commonly.

Other software deployment patterns, for example redirecting password
authentication through some stack such as PAM, also ends up requiring a
plaintext password on the server.

While these patterns are not as secure they are very common.