Subject: [dispatch] Review of draft-campbell-sip-messaging-smime-00

From: Cullen Jennings <[email-masked]>
Date: Mon, 6 Nov 2017 06:54:17 -0800

Relevant comments ...

I have implement S/MIME for encryption with SIP and Simple and I think this document provides some excellent clarifications and updates. 

I agree with the the new MTI ciphers. 

Overall, I think the update in this draft improves the security defined in SIMPLE and MSRP. 

Some random food for thought ....

Getting a cert that says sip:[email-masked] signed by a LE^H^H some CA is hard. However, getting a cert that says fluffy._sip._users.cisco.com is easy and now can be highly automated. Why not allow certs that looks like that. I realize this is going to cause people to just go "that is so wrong", issues certs with the right thing. But back up for a second and ask what the hardest part of any PKI is.  If th cisco.com domain issues me the email address fluffy, it is pretty easy for it to also publish the TXT records I need for domain validation with the CA. This suggestion does not relevantly reduce the security and is is pretty pragmatic.  The problem is not making it hard for the bad guys, the thing we need most is making it easy for the good guys.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Nov 2017 09:48:14 -0600

Thanks for the feedback! Your comment about cert naming is interesting. Russ, do you have thought there?

Thanks!

Ben.

> On Nov 6, 2017, at 8:54 AM, Cullen Jennings <[email-masked]> wrote:
> 
> 
> Relevant comments ...
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Nov 2017 11:38:01 +0000

On Mon, Nov 6, 2017, at 02:54 PM, Cullen Jennings wrote:
> 
> Relevant comments ...
> 
> I have implement S/MIME for encryption with SIP and Simple and I think
> this document provides some excellent clarifications and updates. 

I have implemented S/MIME signing and encryption in email. I found the
document to be well written and have good level of details.

> I agree with the the new MTI ciphers. 

I think I mostly agree with this, although I have to ask why certain EC
curves (like 25519) are not recommended, considering recent work in
Curdle/Lamps WG.