Re: [dane] Question regarding RFC 8162

[Metin Savignano]

Hi Minar, 

I appreciate your response, and I hope these suggestions are going to be 
considered in the RFC.
 
> I’m happy to hear you bring this up, since I also agree that we are missing 
> an important mechanism for clients to specifically search for a signature vs 
> encrypting cert record on DNS -- it’s unfortunate the current RFC did not 
> address this.
>  
> There was an older idea bounced around that we implemented for daneportal.net 
>  of having dedicated meta domains for those two:
> E.g. Jane Doe’s encrypting cert would be an SMIMEA record under 
> “._encr._smimecert.example.com ”, and 
> her 7 signature certs could all be in “._sign._smimecert.example.com 
> ”.
> For the basic RFC compliance, this is done in addition to putting a copy of 
> all those records in the usual ._smimecert zone.
> Clients that are wise to that non-standard _encr/_sign domains could speed up 
> cert resolution with that pathway, but could always fallback to the standard 
> _smimecert domain. The cert attributes are only considered if the USAGE calls 
> for it (PKIX-CA/EE constrained).

Shouldn’t this become part of the standard? 

Due to the relatively large size of SMIMEA records (if they hold the full 
certificate), I think it should be avoided to generate unnecessary traffic. If 
separate certificates are used for encrypting and signing, then it may 
desirable to transfer only the one that is needed. On the other the MUA will 
probably need both sooner or later, so perhaps it’s not so much of real world 
problem as I was thinking.

I guess I understand that your approach is a bit different than our scenario. 
Our original idea was that it should be possible to retrieve a company’s own 
root certificate from the DNS, so to verify any S/MIME certificate that has 
been issued by it. This idea implies that the S/MIME certificate itself has 
already been received by the MUA in a signed email and only needs to be 
verified.

Your approach seems to go a step further by trying to enable the MUA to send an 
encrypted email to some other user of whom it does not have received a 
certificate at all yet, right?

I think both scenarios are absolutely valid and should be considered by this 
RFC.

Metin


___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] Question regarding RFC 8162

[Tawhidul Islam]

Hi Metin,

I’m Minar, an author of daneportal.net where we implement SMIMEA records in 
federated DANE cert provisioning. I’m happy to hear more DANE discussion! :)

You wrote:

So, for use...@example.edu<mailto:use...@example.edu> through 
use...@example.edu<mailto:use...@example.edu> , you would hit 
*.example.edu<http://secure-web.cisco.com/1m9sVPSr2H8pVH1HJOAF1RrIiLKJY3LofJCjye7q1iYK5IbIreyFPPI0SLhIjFKex1XPcUjIRbccOrw0hC2L5x5uLgtak3TqTOiaNlg_vivDAEt2s0j_ojpa2Zx2_9igqF6Np41tphXKyCDPUgG1Ucm6rahLlCjRvFvjbzyMIawyhcjURZFhaZ13yPe6vR9q5_KBZXpgON91R_9N8OUIlHzbmyyqmvYgfQwtmQtkF97iN5uJNI7Px1oNC-xw6SB-a1I83XYkwEBYnxWPxF9YciGZKXVXTHH2LpqUDgp4S4g32KfZNMOp5V9Ilas_RsMC2h1uEioyfQ21VBXr0IFO5mBfooMrApAmdMXEtJMebgokkA2G9-a8sgShgK41jx0dUW8R9OT8A7wucbfM5Ju1kp1jCu6Dj9mbtFd2I5gd5SEc4F-MxJBRzgEKD-teET4CN/http%3A%2F%2Fexample.edu%2F>
 SMIMEA, which would return the root cert.  Does that make sense?

However, it remained unclear to me if that is intended use? (And if so, how 
should anybody know as it is not mentioned in RFC 8162?)

I’m also curious about that. Maybe this merits a clarification update in an RFC?

It is recommended to use two separate certificates, one for encrypting and one 
for signing. If that recommendation is followed, how does RFC 8162 / RFC 6698 
allow for this? Is it possible to have two records for the same user in the DNS 
(I’m not very familiar with the internals of DNS)?

It is totally possible to have many records for the same user. E.g. for 
j...@example.com<mailto:j...@example.com>, in the DNS this is as simple as 
serving multiple SMIMEA records for the “._smimecert.example.com” 
name.
Absurd example: Jane Doe could have 7 certificates all being served at the same 
time because she likes to change her signing key every day
DANE clients (e.g. using libCanute) could end up using any suitable cert for 
encrypting, and should try all suitable certs for verification (taking into 
account the USAGE field/related CA constraining SMIMEA records).

How could we identify which is which, unless the full certificate (not only the 
key) is stored in the DNS record? Even then, wouldn’t it be more practical to 
use different type values, so the client can specifically look for the the 
record it needs?

You’ve hit the mark -- the attributes are in the cert like usual if it is the 
full cert (SELECTOR=0). But that leaves the shortcoming that clients are doing 
extra processing/bigger DNS responses.

I’m happy to hear you bring this up, since I also agree that we are missing an 
important mechanism for clients to specifically search for a signature vs 
encrypting cert record on DNS -- it’s unfortunate the current RFC did not 
address this.

There was an older idea bounced around that we implemented for daneportal.net 
of having dedicated meta domains for those two:
E.g. Jane Doe’s encrypting cert would be an SMIMEA record under 
“._encr._smimecert.example.com”, and her 7 signature certs could all be 
in “._sign._smimecert.example.com”.
For the basic RFC compliance, this is done in addition to putting a copy of all 
those records in the usual ._smimecert zone.
Clients that are wise to that non-standard _encr/_sign domains could speed up 
cert resolution with that pathway, but could always fallback to the standard 
_smimecert domain. The cert attributes are only considered if the USAGE calls 
for it (PKIX-CA/EE constrained).

(Psst that old RFC draft that included this discussion is readable in the 
Canute docs: 
https://github.com/gmu-msl/canute/blob/main/docs/draft-ietf-dane-smime-02-srose.txt
 though the current resolver in that repo is strictly RFC compliant)

That’s my two cents – please do touch back with any more discussion / 
questions! I’d love to collaborate and increase the presence of DANE / SMIME 
implementations.

-Minar

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows


From: dane  on behalf of Metin Savignano 

Sent: Thursday, September 15, 2022 10:37:04 AM
To: Eric Osterweil 
Cc: dane@ietf.org 
Subject: Re: [dane] Question regarding RFC 8162

Hi Eric, hi everyone,

I haven’t seen any reaction my last message yet. I had hoped to get some 
clarification.

You wrote:

So, for use...@example.edu<mailto:use...@example.edu> through 
use...@example.edu<mailto:use...@example.edu> , you would hit 
*.example.edu<http://secure-web.cisco.com/1m9sVPSr2H8pVH1HJOAF1RrIiLKJY3LofJCjye7q1iYK5IbIreyFPPI0SLhIjFKex1XPcUjIRbccOrw0hC2L5x5uLgtak3TqTOiaNlg_vivDAEt2s0j_ojpa2Zx2_9igqF6Np41tphXKyCDPUgG1Ucm6rahLlCjRvFvjbzyMIawyhcjURZFhaZ13yPe6vR9q5_KBZXpgON91R_9N8OUIlHzbmyyqmvYgfQwtmQtkF97iN5uJNI7Px1oNC-xw6SB-a1I83XYkwEBYnxWPxF9YciGZKXVXTHH2LpqUDgp4S4g32KfZNMOp5V9Ilas_RsMC2h1uEioyfQ21VBXr0IFO5mBfooMrApAmdMXEtJMebgokkA2G9-a8sgShgK41jx0dUW8R9OT8A7wucbfM5Ju1kp1jCu6Dj9mbtFd2I5gd5SEc4F-MxJBRzgEKD-teET4CN/http%3A%2F%2Fexample.edu%2F>
 SMIMEA, which would return the root cert.  Does that make sense?

However, it remained unclea

Re: [dane] Question regarding RFC 8162

[Metin Savignano]

Hi Eric, hi everyone,

I haven’t seen any reaction my last message yet. I had hoped to get some 
clarification. 

You wrote:

> So, for use...@example.edu  through 
> use...@example.edu  , you would hit *.example.edu 
>  SMIMEA, which would return the root cert.  Does that 
> make sense?


However, it remained unclear to me if that is intended use? (And if so, how 
should anybody know as it is not mentioned in RFC 8162?)

And please let me ask a second question:

It is recommended to use two separate certificates, one for encrypting and one 
for signing. If that recommendation is followed, how does RFC 8162 / RFC 6698 
allow for this? Is it possible to have two records for the same user in the DNS 
(I’m not very familiar with the internals of DNS)? 

How could we identify which is which, unless the full certificate (not only the 
key) is stored in the DNS record? Even then, wouldn’t it be more practical to 
use different type values, so the client can specifically look for the the 
record it needs?

Please forgive me for dumb questions.

Thanks!
Metin

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] Question regarding RFC 8162

[Metin Savignano]

Thank you very much for your quick reply!

> I think it’s great that you’re looking this!  To answer your specific 
> question, I understand that different people have differing levels of 
> interest in signing vs. encryption (vs. both) for email.  I recall a number 
> of us had discussions about how you could place a root certificate at a 
> wildcard at the mail domain’s APEX, so querying any lhs under that domain 
> would return an SMIMEA record that could be usage type 0 or 2 (PKIX_TA or 
> DANE_TA).  I think that would accomplish your goal of not needed to key every 
> user.
> 
> So, for use...@example.edu  through 
> use...@example.edu  , you would hit *.example.edu 
>  SMIMEA, which would return the root cert.  Does that 
> make sense?

Yes, that absolutely makes sense. However, I wonder if that is intended use, 
and if so, I suggest that it should absolutely be mentioned in the RFC. 


> Just as some context: we, in my lab, are looking into SMIMEA as well and 
> we’ve launched a pilot of an open provisioning infrastructure for managing 
> per-user complexities, MUA add-ons that use DANE for S/MIME, and an open 
> reference implementation of several DANE protocols (DANEportal.net 
>  ,  kurer.daneportal.net 
>  , and libCanute, respectively).  Our goals 
> seem a little different than yours, but would be happy to see if they can 
> help you out.  We presented at the last IEPG, and the students are (I 
> believe) on this list and can respond if you have any other thought!

Looks very interesting, and I appreciate any exchange of ideas and concepts. I 
welcome anything that could help to simplify S/MIME encryption for end users!

Let's stay in touch. 

Thankls
Metin

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] Question regarding RFC 8162

[Eric Osterweil]

Hi Metin,

Comments below:

> On Sep 9, 2022, at 9:41 AM, Metin Savignano  wrote:
> 
> Hi,
> 
> We’re a team working on an email encryption app. I am always a looking for 
> better ways to simplify the use of S/MIME, because I believe that the current 
> PKI is the main reason for people not to use S/MIME. 
> 
> Hence, I’m currently working through RFC 8162 which looked very promising to 
> me. However, while doing so, I stumble upon the fact that it seems to require 
> an SMIME record for each email address – or more precise: for each possible 
> local part of the email address. That does not make lot of sense to me, but I 
> would expect that you have your reasons, which I just don’t understand.
> 
> Let me explain what I’m trying to achieve:
> 
> There are numerous companies (including my own little team) that establish 
> there own CA. I’m looking for a way to publish to the root certificate of 
> such a CA in a way that it can automatically be retrieved and trusted by a 
> remote mail client. It seemed like this could be with DANE using the SMIMEA 
> record. I would expect that I can publish an SMIMEA record with certificate 
> usage 0 (PKIX-TA) that would be retrieved and used to validate the PKIX path. 
> 
> Well, as I understand the RFC, that could be done, but I would have to repeat 
> it for each and every possible local part of the email address. However, I 
> would rather want to publish just one record for the domain part, no matter 
> which local part is used in the email address.
> 
> So my question is:
> 
> Did you think of this scenario? Why is this option not described in the RFC? 
> Am I missing something?

I think it’s great that you’re looking this!  To answer your specific question, 
I understand that different people have differing levels of interest in signing 
vs. encryption (vs. both) for email.  I recall a number of us had discussions 
about how you could place a root certificate at a wildcard at the mail domain’s 
APEX, so querying any lhs under that domain would return an SMIMEA record that 
could be usage type 0 or 2 (PKIX_TA or DANE_TA).  I think that would accomplish 
your goal of not needed to key every user.

So, for use...@example.edu through use...@example.edu , you would hit 
*.example.edu SMIMEA, which would return the root cert.  Does that make sense?

Just as some context: we, in my lab, are looking into SMIMEA as well and we’ve 
launched a pilot of an open provisioning infrastructure for managing per-user 
complexities, MUA add-ons that use DANE for S/MIME, and an open reference 
implementation of several DANE protocols (DANEportal.net 
 ,  kurer.daneportal.net  
, and libCanute, respectively).  Our goals seem a little different than yours, 
but would be happy to see if they can help you out.  We presented at the last 
IEPG, and the students are (I believe) on this list and can respond if you have 
any other thought!


Eric  


___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] Question regarding RFC 8162

[Viktor Dukhovni]

On Fri, Sep 09, 2022 at 03:41:39PM +0200, Metin Savignano wrote:

> We’re a team working on an email encryption app. I am always a looking
> for better ways to simplify the use of S/MIME, because I believe that
> the current PKI is the main reason for people not to use S/MIME. 

I believe this misses much deeper reasons why S/MIME and PGP are not
in common use:

* Even with key distribution solved, once S/MIME or PGP email
  is delivered, it is basically unusable with today's email
  client software and storage architecture.

  - Encrypted messages are not indexed and cannot be
effectively searched.

  - Encrypted messages are not re-encrypted for long-term
storage under managed storage keys, independent of the
"short-term" recipient keys.

  - Signature verification at time of receipt is not securely
recorded along with the message.  Messages look invalid
when signer keys later expire.

  - If E2E key discovery becomes broadly available, spam and
malware defence at the gateway becomes problematic.

  - Which probably means that E2E encrypted email can't be as
permissionless (and therefore as ubiquitous) as mainstream
email (ideally with hop-by-hop encrypted transport).  The
architecture for managing permitted senders of E2E-encrypted
email is not in place, and in any case limits its use-cases.

Poor *usability* of already delivered E2E-encrypted email is a much more
important barrier than lack of key discovery, which IMHO is mostly for
lack of demand, than lack of potential ways to scalably distribute keys.

> Let me explain what I’m trying to achieve:
> 
> There are numerous companies (including my own little team) that
> establish there own CA. I’m looking for a way to publish to the root
> certificate of such a CA in a way that it can automatically be
> retrieved and trusted by a remote mail client. It seemed like this
> could be with DANE using the SMIMEA record. I would expect that I can
> publish an SMIMEA record with certificate usage 0 (PKIX-TA) that would
> be retrieved and used to validate the PKIX path. 

If you're looking for S/MIME restricted to just *signing*, this could
work, but S/MIME supports encryption as a primary use-case, and for that
per-recipient public keys need to be available, not just the issuing
CA's.

-- 
Viktor.

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane