Re: [dane] draft-ietf-dane-smime

[Doug Montgomery <[e-mail]>]

I am a little confused as to why we seem to couple the use case of key
discovery and distribution in TLS to the use case for
email/network-identity.   These seem to be very different use cases to me.

I looked back at two years of data.   My own, mid-size (3K staff)
organization revokes on average 165 net-identities a month.  We also create
about that number, less you think we are withering away.

Having a scalable, simple, but definitive way to indicate that a previously
valid email-identity/certificate is no longer valid within a given domain
is a useful feature that doesn't seem to have an analog use case in TLS.
  As far as I know we have never revoked our TLS cert ...

I know of other industry sectors attempting to develop rather complex
pub/sub architectures to signal changes in status of email identities from
large mailbox providers to other users/uses of the ID.

Overly coupling the use cases and requirements between these uses seems to
be a red herring to me.    Maybe we should turn the question around and ask
for an explanation why the use cases for TLS should impact the requirements
for SMIMEA?

dougm


On Tue, Sep 30, 2014 at 4:53 PM, Paul Hoffman <[e-mail]> wrote:

> On Sep 29, 2014, at 5:26 AM, Osterweil, Eric <[e-mail]>
> wrote:
>
> > Based on our implementation experience we would like to suggest that the
> following text (taken from Scott Rose's email:
> http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be
> incorporated into the current version of the draft-ietf-dane-smime
> document.  We are sending text (below), but at a high-level, the text
> outlines a few useful additions:
> >
> > 1 - Usage #4 (reject) is likely to be very important.  This could either
> emphasize the difference between saying, ``don't use this cert for this
> operation,'' and ``this cert is universally revoked'' or be used to
> selectively override an organization-wide TA for certain employees that
> have left the organization.
> >
> > 2 - The certificate access field (Section 2.1.4) would enable alternate
> discovery mechanisms that could help aid incremental deployment and
> transition schemes.  For example, while cutting over to a DANE solution,
> some enterprises may want to transition users from (say) AD to DANE, and
> this field would enable that.
> >
> > 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the
> management of zone sizes and lookup sizes.  Rather than querying for all
> keys and then locally selecting from them, I (as an RP) likely already know
> which of these I want, and I should be able to look them up separately in
> DANE (and owners should be able to manage them separately in DANE).
> >
> > If anyone objects, please let us know.
>
> Jakob and I think that the three additions are unneeded here, and make the
> draft diverge quite far from the TLSA format without significant value. In
> specific:
>
> 1) This usage type is at least as applicable to TLS as it is to S/MIME. We
> haven't seen anything indicating much use of certificate revocation
> anywhere and, where we have seen it, it is much more common in TLS. If the
> authors really want this feature, it should be an update to TLSA, which
> SMIMEA could then adopt.
>
> 2) Making the record format for SMIMEA different than that of TLSA for
> this feature seems like a bad idea. Alternate discovery mechanisms might be
> important, but they will be just as important for TLS as they are for
> S/MIME. The functionality that the authors want could be added to TLSA by
> adding new Matching Type fields such as "Hash and NAPTR", "Hash and URI",
> and so on. The latter is part of IKEv2 (although the feature is generally
> considered not useful). If the authors really want this feature, it should
> be an update to TLSA, which SMIMEA could then adopt.
>
> 3) There is absolutely no indication that zone size or response size is
> important to SMIMEA, certainly not relative to the added complexity for
> clients, servers, and operators. Currently, the RSA certs for SMIME from
> common CAs are for both signing and encrypting, so this added complexity
> won't buy current users anything. In the future when we are all (hopefully)
> using elliptic curve keys, the zone size and response size will be so much
> smaller than they are now that this change will appear as an
> over-optimization that adds complexity.
>
> When these ideas were brought to the WG earlier this year, we didn't hear
> any significant support. Given that both of us feel that the proposed
> changes make the document harder to implement, we would want to see much
> wider support before we adopt them.
>
> --Paul Hoffman and Jakob Schlyter
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>
>


-- 
DougM at Work