<chair-hat>
Thank you Sean
for supplying numbers and reasons to consider all the points.
Wg members, please start giving feedback on this tread as to going forward,
should we in the S/MIME DANE documents explicitly support “policy expression”
or
reject it.
</chair-hat>
<personal-hat>
to me one question to answer is:
If X@Y sends S/MIME signed message to DANE WG on January 20’th 2016.
X@Y leaves Y on Feb 15’th 2016.
Is there any value in being able to validate the signature when a document
editor gets around to read the message March 15 2016
while updating the document referenced in the email to meet the ID deadline for
IETF-95 ?
Olafur
On Oct 16, 2014, at 1:46 AM, Sean Turner <[email protected]> wrote:
> Apologies for coming to this late and for this being so long.
>
> On Sep 30, 2014, at 16:53, Paul Hoffman <[email protected]> wrote:
>
>> On Sep 29, 2014, at 5:26 AM, Osterweil, Eric <[email protected]> wrote:
>>
>> 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
>
> I guess we know where the authors stand on making the changes ;)
>
> Anyway, put me in the camp that wants to continue the discussion about the
> possibility of making changes to support the proposed changes to the SMIMEA
> spec.
>
> WRT:
>
>> 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.
>
>
> Two parts:
>
> 1) Comparing the use of revocation of TLS certificates to S/MIME certificates
> is an interesting way to start because what you say is obviously true; TLS is
> so much more widely deployed compared to S/MIME (everybody uses TLS -
> enterprises and some nerds use S/MIME) so of course you’re going to see it
> much more in/for TLS. I’d love to know the split between TLS versus S/MIME
> certificates issued by big box CAs and how often the associated CRLs get
> checked but I’m sure that’s proprietary (please somebody prove me wrong).
>
> 2) I want to push back on the statement above about changing TLSA first and
> this bit that followed later in the thread:
>
> On Oct 02, 2014, at 18:12, Paul Hoffman <[email protected]> wrote:
>
>> On Oct 2, 2014, at 1:56 PM, Doug Montgomery <[email protected]> wrote:
>>
>>> 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?
>>
>> Or, based on what Jakob and I suggested, why shouldn't features that are
>> needed for either use case be shared?
>
> The idea that the proponents of these changes need to go change the TLSA spec
> because you think it applies to both seems a little bit excessive. If you
> think the changes apply to both, then great feel free to go and propose those
> changes get made in the TLSA spec; I see no reason to burden the proponents
> of these changes with that job.
>
> WRT rarity:
>
> On Oct 02, 2014, at 18:12, Paul Hoffman <[email protected]> wrote:
>
>> On Oct 2, 2014, at 1:56 PM, Doug Montgomery <[email protected]> wrote:
>>
>>> As far as I know we have never revoked our TLS cert ...
>>
>> Right: TLS certs are rarely revoked. This can be seen by looking at the CRLs
>> from major CAs. However, looking in those same CRLs shows nearly no S/MIME
>> certs revoked either.
>
>
> There might be other reasons to dismiss usage #4 (reject) but we shouldn't do
> so based on your assertion that there’s no revocation of TLS or S/MIME certs
> because I believe revocation happens more than rarely. Rarely to me means
> I’d have a really hard time finding some revoked certs.
>
> I took the bait and went and looked at some CRLs (my hastily gathered small
> sample is later) - was this your ploy all along? If not, I’d be curious to
> know what you’re looking at to motivate your statement. What I’m looking at
> seems to indicate that TLS certificate revocation happens certainly more than
> on rare occasions. I also got my hands on some CRLs with S/MIME certificates
> on ‘em that also seem to indicate it’s also not so rare to revoke S/MIME/ID
> certificates (also later).
>
> Note: This might be stating the obvious but looking at the exact same CRLs
> might not give you what you’re looking for in terms of finding revoked TLS
> and S/MIME certificates: 1) the CA has to put all the revoked certificates on
> the same CRL and they don’t always do that in fact it looks like many don't
> that based on the CRL’s issuer name; CRL issuer names include “EV”, “SSL”,
> etc. for TLS-only CRLs and “Individual”, “Personal”, etc. for S/MIME-only
> certificates, 2) some of the big box CAs only do TLS certificates so of
> course you’re not going to see any S/MIME certificates on the CRL, and 3) you
> can’t tell by looking at CRL entry what the certificate’s KU or EKU is
> because the entries only contain the serial number, revocation date, and
> maybe if you’re lucky a revocation reason (you might be able to infer from
> the reason code but you kinda gotta guess what’s on the CRL based on the name
> of the CRL issuer or if you dig a little farther based on the certificate’s
> CP/CPS - I mostly assumed based on the CRL issuer name).
>
> Before the data first a couple of disclaimers:
>
> - I don’t name names for obvious reasons.
>
> - The CRLs are all from public facing TLS servers. So all of this in some
> fashion or another is reproducible.
>
> - I made sure to not use duplicate CRLs from the same provider by looking at
> the AKI if present and issuer name if not.
>
> - To find the CRLs, it wasn’t as easy as following some links to the CA’s
> repo and downloading them; it is that easy for root and intermediate CA
> certificates but not for CRLs and not for EE certificates. Maybe I’m doing
> it wrong … anyway, to get them I had to go to https enabled websites, click
> on the browser bar, inspect the certificate, scroll to the CRLDP extension,
> ctrl-c/v the URI to the CRL into firefox, then use dumpasn1 (still works like
> a champ) on the downloaded CRL to look at the number of entries. I then went
> to the SEQ after the thisUpdate/nextUpdate lines, divided the number next to
> the SEQ by what seemed to be the average size of each entry, and got an
> approximate # of entries on the CRL. See [1] for some interesting
> observations. Also, if you’re looking at the CRL’s pointed to in those CA
> certificates you can find in the repo you’re looking at the wrong CRL - the
> CRLs pointed to from CA certificates are ARLs disguised as CRLs.
>
> - Other folks were more high tech and ran scripts that looked at a lot more
> CRLs than my manual method. I included their results after my plodding
> results.
>
> And, now for some data on CRLs for TLS certificates:
>
> - Started with search engines: two of ‘em run their own CAs so it’s
> unsurprising they contain few entries (8 & ~50) and another uses a managed
> service and that CRL has well more … like ~51K. The CRL with ~51K entries
> includes entries back to 2010 and according to the description of the Root CA
> only TLS certificates are issued by CA subordinates to it so all of those
> ~51K are TLS certificates. I went to another one - they don’t offer https://
> :(
>
> - A non-US news organization: there’s ~400 entries covering just this year.
>
> - A non-US bank: ~5.2K entries with three years worth of revoked certificates
> (no reason codes). I went to another on a different continent and found the
> same CRL so new data. I went to a third (on the same continent as the 1st)
> and got a CA from what I wouldn’t consider one of the typical US big box CAs
> and found a CRL with ~35 entries from 2014 - no reason codes.
>
> - A non-US tech company: ~10K revoked certs over 4 years with no reason
> codes. Another one on a different continent: ~1.8K entries spanning 3 years
> - reason codes too codes 5, 4, 3, and 1 (in descending order of apperance).
>
> - From a couple of the larger hosting sites: one runs their own CA and it has
> ~280 entries - all in one year and all but one reason code is 5, another
> doesn’t run their own CA and the CRL in their certificate has ~2.8K entries
> but no reason codes (all in 2014), another one has an empty CRL, another one
> has a CRL with ~500.
>
> And now for more comprehensive data:
>
> Eric Osterweil has some data that can be found here:
> http://secspider.verisignlabs.com/heartbleed/
>
> Richard Barnes had some too: scan of CRLDPs in ~450
> different CRLs: 1.4M entries, median entries per CRL: 390,
> average # of entries 3.2K
>
> This doesn’t seem so rare.
>
> Onto S/MIME:
>
> On Oct 02, 2014, at 18:12, Paul Hoffman <[email protected]> wrote:
>
>>> I looked back at two years of data. My own, mid-size (3K staff)
>>> organization revokes on average 165 net-identities a month.
>>
>> This is literally the first data I have seen that indicated that email certs
>> were revoked for other than far edge cases. (I'm assuming that you are
>> equating "net-identities" and email certs...) Thanks for the data.
>>
>> But, having said that, NIST isn't a typical organization. The fact that you
>> revoke more than half of your S/MIME certs per year is surprising to me, but
>> that may be because I am not familiar with the policies you used.
>
>
> I’m just as surprised by the # of revoked certificates compared to the # of
> employees, but I’m also not surprised that the $14.95 and free S/MIME cert
> CA’s CRLs are empty or at least close to it: 19 entries (covering 8 years),
> ~180 entries (covering two years). There’s little incentive for those that
> have been issued $14.95 or free certificates to ask for them to be revoked
> especially since most of the changes I see are cessation of operation (I
> quit, I got fired, etc.).
>
> I think we should be looking at the managed service CA’s CRLs or large
> enterprise CA CRLs instead because there at least there’s policies that are
> much more likely to get enforced (you quit they revoke your cert). Then
> again, you have to dig a little deeper to find these CRLs by CLRDPs in
> certificates with signed messages. Here’s some CRLs from managed PKIs
> (employee #s from wikipedia) picked from S/MIME messages sent to an IETF ML:
>
> - ~120K employees: ~125K entries spread out over 3 years. Of the reasons
> that appear superseded shows up the most then affiliation changed.
>
> - ~100K employees: ~5K entries so far this year. No reason codes.
>
> - ~25K employees firm has ~36.5K entries covering the last three years. Not
> a lot of reason codes but there are 57 key compromise and 244 superseded
> reasons listed.
>
> - (a University) ~18K students & ~2.5K staff: ~1.9K entries spread out over 3
> years. No reason codes.
>
> - An org (don’t know how many people work there - wikipedia failed me):~1.7K
> entries. No reason codes.
>
> Only one of the above is what I’d consider a traditional USG-affiliated org -
> and it’s not the CRL with the most entries.
>
> NIST #s might be out of whack but I’m not sure how atypical it is for
> organizations that actually issue certificates to revoke those certificates.
>
> Again, I’m all for debating whether we should define a “revoke" usage and how
> it works but dismissing the request based on data that to me shows the exact
> opposite of your observation seems wrong to me and I hope others.
>
> WRT:
>
>> 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.
>
> Four points here:
>
> - On the certificate size, you’re right that EC certificates will be smaller
> than their RSA-based brethren. I pulled a RSA-based TLS certificate from a
> US bank it’s about ~2Kbytes. An EC-based TLS certificate, which I thought
> based on the name in the cert was a porn site - not - it’s a bakery, is about
> ~1Kbytes - an S/MIME cert would be the same size.
>
> - On whether it buys current users anything because RSA-based S/MIME
> certificates are for both sig+enc, of course it’s not going to buy them
> anything for my persona-non-validated certificates they don’t offer the
> ability to get just one usage. Also, some do in fact issue separate certs.
> I don’t think you can lump all the users together.
>
> - On the future, the part you didn’t mention is that EC-based certificates
> might not specify both digital signature and transport/agreement. The TLS EC
> certificates I’m seeing only include only sig. Whether the S/MIME certs
> follow suite - I don’t think you can say authoritatively they will or won’t
> unless you’re a CA who is issuing them. If the certificates include both KUs
> then yeah EC certs are about half of RSA certs - but if not then two of ‘em
> is about the same as one RSA cert.
>
> - Finally on complexity, what’s proposed is definitely more than what’s there
> now but how much more complex it is I think is in the eyes of the beholder.
>
> spt
>
> [1] 1) One of the other thing to note for CRLs that span more than one year
> is that the number of revocations seem to be increasing. I could speculate
> as to why but maybe we can leave that for another thread. 2) Some of the
> bigger CRLs are bigger not entirely based on the # of entries it’s also
> because they used longer serial #s and included reasons codes - a 64MByte CRL
> had ~300 entries. 3) Interesting to note that in the EC-based cert the
> spki+(sig+alg id) is like 89+(73+10) octets - could save another 80 octets by
> not including a subject name and just using the SAN.
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
