Re: authmeth - StartTLS security consideration

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
> In respect to the following text:
>   Clients SHOULD by default either warn the user when the security
>   level achieved does not provide an acceptable level of data
>   confidentiality and/or data integrity protection, or be configured
>   to refuse to proceed without an acceptable level of security.
>
> the IESG basically asked "under what circumstances would it
> be acceptable for a client, by default, to proceed without
> any warning with an unacceptable level of security", if none,
> the SHOULD ought to be a MUST.
>
> Though I noted that one such circumstance is where it is possible,
> through subsequent protocol exchanges (e.g., SASL), to achieve an
> acceptable level of security.  However, I didn't see the MUST
> precluding this.

I think it would preclude it, without the added sentence in your
suggested replacement text.  That is, if you mean to keep whatever TLS
layer is established, and try to get enough security by including a SASL
layer as well.

> I personally have no problem with keeping this a SHOULD if someone
> can come up with acceptable text that provides a reasonable
> circumstance where not following the recommendation would be
> appropriate.

What if one requests a null layer because one has no interest in the
security aspect of TLS, but only in exchanging certificates?

This also reminds me of the ldap.conf option "TLS_REQCERT <allow/try>"
in OpenLDAP - inherited from Umich LDAP, I think.  These options request
the server certificate, but proceed if it is not provided, or (for
"allow") even if it is invalid.  I do not understand the purpose of
these choices.  Whatever the rationale is, is it also relevant for this
authmeth paragraph?

> I also noted that second half of this text appears to place
> a SHOULD upon the user (or admin) and not the implementor.
> The RFC 2830 text:
>    Clients SHOULD either warn the user when the security level achieved
>    does not provide confidentiality and/or integrity protection, or be
>    configurable to refuse to proceed without an acceptable level of
>    security.
> is better in this regard.  I believe it was rewritten to imply
> that the default configuration should be to 'refuse to proceed'
> or 'warn'.

Yes, that is my recollection.  Though there was some other tweaking too.

> Considering all of the above, the following replacement text
> is offered for WG consideration.
>
>   Clients MUST by default either warn the user when the
>   security level achieved does not provide an acceptable
>   level of data confidentiality and/or data integrity
>   protection, or refuse to proceed without an acceptable
>   level of security.  This requirement is not intended
>   to preclude a client from attempting to achieve an
>   acceptable level of security via other means (e.g.,
>   SASL), or combination of means.

Much better.  However, now that I'm looking at this:

- It leaves out an option the drafts discuss elsewhere: Gracefully
  close the TLS layer, and proceed without TLS.  Depending on what
  the client is for, it may or may not be OK to do this silently.

- I suggest to start the text with

    By default, clients MUST ...

  to clarify that "by default" applies to the entire sentence and not
  just to the part before the first "or".

-- 
Hallvard