[UA-discuss] OpenSSL, was Where should IDN translation happen?

[Dmitry Belyavsky]

Dear Michael,

I suggest leaving aside the delivery and corresponding verification of
addresses by MTA.
It seems to be out of the scope of OpenSSL.

Please correct me if I am wrong.

On Thu, Nov 15, 2018 at 2:54 PM Michael Casadevall <michael at casadevall.pro>
wrote:

>
>
> On 11/15/18 3:29 AM, Dmitry Belyavsky wrote:
> > Dear John,
> >
> > On Wed, Nov 14, 2018 at 7:59 PM Dmitry Belyavsky <beldmit at gmail.com
> > <mailto:beldmit at gmail.com>> wrote:
> >
> > I've got a response from Victor Dukhovni. His position is:
> >
> > 1. It's better to ask OpenSSL about their plans :) via
> > openssl-project at openssl.org <mailto:openssl-project at openssl.org>
> > 2. (Limiting scope to EAI certificates) OpenSSL must trust the CA
> software
> > that has provided punycode representation of the domain name. So we can
> > decode
> > A-labels and compare them. So the certificate itself can be verified,
> > and questions
> > whether the EAI address matches the address in From: header is out of
> > scope of the
> > certificate validation process.
> >
>
> That doesn't sound right at all ...
>
> RFC 7508 (https://tools.ietf.org/html/rfc7508) specifically handles how
> the email headers are protected by S/MIME verification (and OpenSSL
> specifically supports embedding these headers with their own command
> line tool).
>

I did not find this special handling, at least by 'grep -ri SecureHeader'.
Either I did not find it in man cms/man smime.


>
> RFC 8398 (https://tools.ietf.org/html/rfc8398) specifically lists out
> the cases of where either an A-label or U-label go in the certificate;
> it's complicated but basically depending on the LDR component, it can be
> an A-Label or U-Label.
>
> Depressingly, it doesnt look like OpenSSL supports SmtpUTF8Mailbox at
> all (or at least I can't find it with a grep). As to how this all works,
> Dmitry, here's my understanding.
>

Sure. I do not know about other implementors of RFC 8398 except me.
And my implementation is very limited too.


>
> The short version here is that the From: and To: field is specifically
> set by the user, and is used in SMTP specifically as the MAIL FROM and
> RCPT TO commands. These could be A or U labels as they're user entered.
> Both should generally support UTF-8, is used for bounced emails (which
> can be S/MIME signed if the MTA supports it). Because of this, the
> From/To field should always be U-Labels, and the MIME fields be those
> resulting U-Labels; they shouldn't ever be converted to A-Labels directly*
>
> I haven't gone through the RFCs to make sure of this, but this is what I
> recall off the top off my head. For a EAI-to-EAI email the following
> steps need to happen
>  - MUA sets From and To fields as U-labels
>  - MUA to sends email to their outbound SMTP server
>  - The SMTP server breaks the email into the user part and the domain
> part, the domain part is converted to an A-label
>  - If DANE is being used, the outbound server checks TLSA records after
> STARTTLS
>  - IDN translation happens if necessary, standard SMTP processing
> happens here. MX records are downloaded, checks against DKIM/SPF run
> against the A-label of the From field address
>  - Receiving SMTP server gets MAIL FROM/RCPT TO in U-Label form
>  - Mail is delivered.
>

This seems to be out of scope of the OpenSSL toolkit but in scope of the
MTA in whole.


> S/MIME adds the following additional steps:
>  - When an email is sent, *before* it is submitted to the SMTP server,
> MIME headers are duplicated, and signed within the message body. This
> prevents the headers from being tampered with in such a way that they're
> undetectable. The email (with headers) is signed with the receiver's
> public key.
>

Do you mean signing with the sender's public key or encrypting with the
receiver's public key?


 - When the email is received, the email is decrypted, and the From
> field is matched to the CN/SAN fields in the S/MIME certificate to know
> which public key to load/verify. If this mismatches, the email gets a
> broken lock.
>

There may be more than one reason to get a broken lock icon.
1. The trust chain cannot be established. RFC 8398 provides extra cases
when it happens.
But there we can refer only on CA software that provides A-labels and
U-labels in nameConstraints
and SAN. I do not think that it's a good idea to correct CA behaviour in
OpenSSL.

2. The chain of trust is established, but the certificate used for signing
does not match the From: address.
This can happen in case of bad EAI representation either in the certificate
or in MTA/MUA of sender.
I think that MUA are a legitimate place to ensure IDNA2008-compliance here.

3. Everything is OK on stages 1-2, but the signature is broken.
Nothing seem to depend on EAI here, because the signature depends on data,
not on its semantics.
It seem to be verified on the OpenSSL level too.


>
> For verification to work as the OpenSSL guys say, verification would
> fail because the From label would be a U-label, and the cert would have
> an A-label. From where I'm sitting, validation should pass if the From
> field is punycoded for compatibility with old/broken MUAs/MTAs as long
> as it comes out to the right thing and the cert should always what spec
> says.
>

As I wrote before, there are at least 3 possible way to fail the
verification.


>
> If I got anything wrong from the RFCs, corrections welcome, but this is
> how I understand how it should work  but I could very easily gotten the
> finer points wrong.
> Michael
>
> * - an exception exists for Forwarded-By/Path headers amended by SMTP
> which could reasonably put an A label in to allow emails to pass through
> non EAI-aware SMTP servers; that should work as long as the starting and
> end point are both EAI aware.
>

So I think if we can together work out suggestions on how OpenSSL can fit
our requirements,
we can then either provide it to OpenSSL team or I can implement some
patches to be somewhen merged.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20181115/db1aecb1/attachment.html>