Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?

[Ned Freed <[e-mail]>]

> On 17 Jan 2010, at 17:35, Ned Freed wrote:
> >> Shouldn't we be seriously discouraging that usage?
> >
> > Perhaps. But a provisioning mechanism specification isn't the place to do it.
> >
> The specification, if it describes the method of "Wrapped SSL",

If by "description" you mean a single sentence, I guess this specification
qualifies. But by that measure, RFC 2595 would probably qualify as well.

> must explain what's wrong with it, and we know too well what's wrong with it
> (implementation specific behaviours, IANA problems, negotiation problems,
> although the latter is addressed in part by this very specification).  If it
> doesn't describe a specification that the IETF wrote or vouches for, then that
> specification needs to be written.  Otherwise, it shouldn't specify its usage
> at all.

The consequences of that will be to make the mechanism unusable for a
nonnegligable number of deployments. Deployment of this is going to be
difficult enough without such well-meaning but strategically foolish
exclusions.

> Happily, this specification *does* explain the procedure for wrapping
> POP/IMAP/SMTP inside a directly-negotiated SSL stream, so all that's required
> now is to explain why, in all this time, we haven't documented it before now. 
> Perhaps we can even kill two birds with one stone. :-)

But we have documented this at this level of detail before now - in RFC 2595
section 7.

Now, I have no objection to adding a sentence to the security considerations
section saying that use of imaps/pops are discouraged and pointing to the
previous text on this issue. But I see little if any value in repeating the
explanation here. And I'll again repeat that if your goal really is to change
existing deployment practices, the only chance you have of doing that is with a
separate document specifically on this point and this point alone.

> > If you want to promote or discourage a particular approach to deploying network
> > services, you need to do it directly. Write a "IMAPS/POPS considered harmful"
> > draft and get it published.

> See above; I have no problem with propitiating those who choose to do it
> wrong, but only so long as they don't do it very wrong, and hurt lots of
> innocent bystanders who obey well-written rules as a consequence of their own
> desires.  The deployment or not of broken vs correct behaviour will speak for
> itself, and I have no problem with that.  But neither should we simply allow
> for the specification of broken behaviour without a cautionary note.

The relevant cautionary note has been part of our specifications for other 10
years now.

				Ned