On Thu, Nov 05, 2015 at 06:53:46PM -0500, Dave Garrett wrote:
> On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote:
> > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote:
> >
> > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote:
> > > > I'd like it to say:
> > > >
> > > > * The signature algorithms of self-signed certificates are
> > > > not subject to any constraints on either the supplicant or
> > > > the verifier. They are not required to match the supported
> > > > signature algorithms of the peer, are not required to avoid
> > > > deprecated algorithms, and their self-signatures SHOULD NOT
> > > > be checked.
> > >
> > > Why "SHOULD NOT be checked"? I don't think it needs to say anything
> > > about checking self-signatures here, one way or another.
> >
> > The verifier always has a trusted out-of-band copy of each
> > trust-anchor. Checking the self-signature may needlessly run into
> > problems when its deprecated algorithm is no longer even implemented
> > in the crypto library. And yet the trust-anchor is still fine.
>
> Ideally, if the implementation is trusting certs as a whole, then it should
> be attempting to validate self-signatures upon addition to the trust store.
> If the cert received matches exactly, then it has been checked; redoing
> it isn't helpful. I note "attempt to validate" and agree that failing but
> still agreeing to trust the cert could be fine. Essentially, I'd rather
> it say something to the effect of: "Trusted self-signatures SHOULD be
> validated before adding to a trust store and SHOULD NOT be re-checked at
> runtime." But we're getting slightly out of scope here, which is why I'm
> thinking that elaborating on this topic exactly as suggested is not needed
> in the document.
Good, we essentially agree on the preferred implementation behaviour,
what remains to quibble over is how explicit the text should be in
that direction. And your more nuanced formulation is fine.
I think that some implementation guidance is reasonable, but it
can be weaker than "SHOULD". Implementations need to be strict
where necessary, but being "strict" where unnecessary is bad,
because connections break or downgrade to cleartext in cases that
would otherwise just work.
Having seen both a considerable lack of necessary checks in many
implementations, *and* a considerable excess of counter-productive
unnecessary checks, I prefer to give implementation guidance where
there is non-negligible risk of either type of error.
This particular issue is one where Schannel, for example, is at
present not implemented correctly. It aborts handshakes when
clients present CAcert.org issued certificates along with the issuer
root CA cert. In SMTP to outlook.com this typically downgrades
STARTTLS to cleartext for senders configured with client certs as
described.
Yes, I still agree that this is not a major issue, and if the core
issues around client and server obligations are sorted, I can live
with silence on this question if it is felt that guidance of this
type detracts too much from the document.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
