Subject: Re: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work)

From: Tom Ritter <[email-masked]>
Date: Fri, 1 Apr 2016 11:36:02 -0500

If people are unaware, protection of email headers (for PGP) is
progressing at https://modernpgp.org/memoryhole/ (although it may be a
bit stalled.)

-tom

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2016 12:43:27 -0400

> progressing at https://modernpgp.org/memoryhole/ (although it may be a

This looks like the usual approach of wrapping the message in an outer 
message with all of the headers genericised.  Ned Freed has said this has 
severe patent problems.  I don't know the details.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Wei Chuang <[email-masked]>
Date: Fri, 1 Apr 2016 10:47:08 -0700

There's also an experimental RFC7508 "Securing Header Fields with S/MIME"
plus RFC5751 mentions using message/rfc822 though that is not completely
specified.  One issue likely common with these approaches is keeping
private the sender and recipient(s).  I've pitched the idea of doing some
form of onion routing to mitigate that.  Hopefully these are things folks
would be interested in pursuing.

-Wei

---

From: Tom Ritter <[email-masked]>
Date: Fri, 1 Apr 2016 13:16:21 -0500

On 1 April 2016 at 12:47, Wei Chuang <[email-masked]> wrote:
> specified.  One issue likely common with these approaches is keeping private
> the sender and recipient(s).  I've pitched the idea of doing some form of
> onion routing to mitigate that.  Hopefully these are things folks would be
> interested in pursuing.

I'm super interested in that.

I've been interested and worked casually on mix networks for a bit,
for strong anonymity. But there are lots of problems there, including
reliability (and throughput) of nodes, abuse, and of course the 'going
dark on spam' problem . Lately I've been thinking about something
weaker and potentially more deployable.

Model it as four parties at play: Sender, Receiver, Sender Provider,
Receiver Provider. Right now each party sees everything - goal is to
reduce that.

One idea I've had is that each provider can publish a
[email-masked] address.  You encrypt a message to
[email-masked] specifying [email-masked] as the recipient with
the body additionally encrypted (or not) to Alice. Google decrypts and
then forwards to Alice. This makes the Recipient private from the
Sender Provider, and doesn't impact any sort of incoming spam
controls.  (It does impact outgoing spam controls to a certain
degree.)

Another idea is that the sending provider can strip all identifying
information from the message as it passes through them. The
information is contained inside the encrypted envelope to the final
recipient. Sending provider will still know who's sending the message
(SMTP authentication) - but the Receiving Provider doesn't learn the
Sender.  You've got lots of concerns about impersonation here, but I
think we could device a cryptographic protocol that gives the Sending
Provider assurance the Sender isn't trying to masquerade as someone
else. (The simplest one would just have the Sending Provider encrypt
the Sender to the Recipient.)

-tom

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Apr 2016 20:21:45 +0100

Hiya,

On 31/03/16 20:08, Stephen Farrell wrote:
> 
> And separately, I'd like to try get interested folks who'll be
> at IETF95 together for a chat if we can.

If you're interested in this and at IETF95, I've booked a room
(Paraiso, 5th floor) for Thursday 1945 to chat about whether or
not we seem to have enough work and interest to charter a WG
for some of these. I think we should aim to be quick about that
so I've just booked 30 minutes. Chat can of course continue
after that at bits'n'bytes or elsewhere.

Please send me an offlist reply to this if you'd like to take
part, just for room-size.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Apr 2016 18:40:57 +0100

Hiya,

I got 10 folks saying they'll come which is the capacity of the
room and since I should probably also be there we're changing
the room to Atlantico A at the same time (1945 Thu). That holds
about 40 which should be plenty so no more need to ping me and
say you'll come, just turn up if in B-A and interested.

Cheers,
S

On 04/04/16 20:21, Stephen Farrell wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 7 Apr 2016 18:28:07 -0300

Hi all,

I really welcome this initiative - I think there are items that should 
be worked on and the closing of the pkix prevented any real advancement 
in the PKIX workspace that definitely impacted the deployment of PKIs 
and strong authentication (especially client-side). I added some work 
items that were discussed at the time the WG was closed in the form of 
comments in the GDocs document. Although I think this could tackle the 
issue of having "Trust Lists" in applications (e.g., browsers, etc.) - I 
refrain to add some work items to the document that might be perceived 
as "boil the pki ocean" (e.g., an infrastructure for discoverability of 
Internet PKIs - http://dl.acm.org/citation.cfm?id=1750404) at this time 
and do not want this good initiative to fail because of this...

Stephen: thanks for being open to this possibility and start the 
discussion :-D

Looking forward to the meeting later.

Cheers,
Max

On 3/31/16 4:08 PM, Stephen Farrell wrote:
> Thanks for doing that.
>
> What I'm most interested in for now is who would implement and/or
> deploy which bits of possible work. So if you can annotate Wei's
> document with that kind of information or otherwise make that
> clear on the list, that'd be very useful. (Please note that I am
> much much more interested if someone says they'd implement,
> compared to someone just expressing interest or wishing that
> someone else would implement.)
>
> at IETF95 together for a chat if we can. At the moment, either
> Monday lunch or Thursday about 8pm (during bits'n'bytes) seem
> like they'd work for me. If you'd come along please send a mail
> to me, Wei and John Levine and we can see what's likely best.
> (If you really like to be involved in that but are remote, do
> say so. I'm not sure having many remote folks will work so well
> for this kind of discussion but we can try if need be.)
>
> Cheers,
> S.
>
> PS: I'll be travelling from tomorrow so offline a good bit,
> but please keep the discussion going on the list.
>
> On 31/03/16 19:59, Wei Chuang wrote:
>> Hi all,
>>
>> I've created a Google Docs of the potential work items and discussion
>> summary (associated with my personal email account).  This will make it
>> easy to take comments on the document and incorporate them into the
>> document easily.  The following link goes to the document:
>> https://goo.gl/xXbBoc  (i.e.
>> https://docs.google.com/document/d/1bZ9BHiw1FvTj1HKEWlfUqe4811KroY_Ottzl3fye-eE/edit?usp=sharing
>> which might get split by some email clients)
>>
>> Here's a link to the help center on how to make a comment in the docs:
>> https://support.google.com/docs/answer/65129?co=GENIE.
>> Platform%3DDesktop&hl=en
>>
>> For those who prefer a text document, I've inlined it below.  Please use
>> the above Google Doc link, because it automates making changes to document.
>>
>> thanks,
>> -Wei
>>
>> ----------
>>
>> IETF PKIX / S/MIME Feb-Mar 2016
>> Work Items
>> Potential work list:
>>
>>
>> Short term:
>> 1. EKU for intermediate CA certificate
>> 2. Manufacturer Usage Description URI certificate extension
>> 3. Certificate i18n email address support
>> 4. Non authoritative key lookup (see bhjl draft)
>> 5. Solving incomplete certificate chains and handing expired certificates
>> cleanly on clients
>> 6. Adding new S/MIME crypto: AEAD: AES-CCB, AES-GCM,
>> AES-CCChaCha20-Poly1305, CRFG ECC Curves
>> 7. Deprecate old ciphers e.g. md5, sha1
>> 8. Support for PGP keys in CMS
>> 9. Update RFC4134 i.e. S/MIME examples
>> 10. drafts
>>     1. draft-lear-ietf-pkix-mud-extension-00
>>     2. draft-lbaudoin-iemax-02
>>     3. draft-ietf-pkix-eai-addresses-00
>>     4. draft-bhjl-x509-srv-00
>>     5. Draft-melnikov-smime-msa-to-mda-04
>>
>>
>> Long term
>> 1. Certificate discovery and reenrollment
>> 2. Solving email address canonicalization (perhaps via bhjl oracle)
>> 3. Header privacy
>> 4. Prevent signature stripping attack
>> 5. Painless client configuration
>>
>>
>> Even longer term
>> 1. Supporting Webmail
>> 2. Preventing Spam
>> 3. Combining PGP S/MIME
>> 4. Email identity
>>
>>
>> ________________
>>
>>
>> Opinions
>>
>>
>> PKIX Mailing List
>>
>>
>> Strings in certificates: Want clarifications in 5280 regarding strings
>> * Date: 18 Jan 16
>> * Issue: Deprecating types; interpretation for DisplayText; Unicode
>> normalization; Control Characters; Unicode for rfc882Name
>> * Discussion: See X.520 and other documentation
>>
>>
>> EKU for intermediate certificates: Allow EKU in intermediate CA cert to
>> allow technical constraints as specified by CABF
>> * Start: 4 Feb 16
>> * Issue: Worry significant change since EKU wasn’t meant to impact path
>> validation; Implementers haven’t been following path constraints very well;
>> Interoperability challenge due to different standards
>> * Proposal: New extension; New interpretation; Follow policy OID; other
>> answers in archive
>>
>>
>> Is it time for a pkix extensions (or similar) wg?
>> * Start: 5 Feb 16
>> * Proposals: Manufacturer cert extension (see lear draft); i18n for cert
>> rfc822Name (see lbaudoin, eai-addresses drafts) spawned address discussion
>> noted below; S/MIME name matching selector in SignerInfo: case,
>> normalization?  What about S/MIME WG (stephen farrell)?
>> * Issue: S/MIME: “biggest problem… how to tell senders what they should
>> do”; successor to S/MIME and PGP?; Enough work for two working group? Or
>> just one working group?
>> * Drafts:  draft-lear-ietf-pkix-mud-extension-00; draft-lbaudoin-iemax-02;
>> draft-ietf-pkix-eai-addresses-00.txt
>>
>>
>> Email address matching rules (was Re: Is it time for a pkix extensions (or
>> similar) wg?)
>> * Start: 6 Feb 16
>> * Issue: email address local part normalization is against RFC5321; Sec 7
>> of RFC5280 needs updating; Security model
>> * Proposal: Sender should normalize (see 5750); define rules in DKIM or
>> DNS; define OTHER-NAME in cert SAN/IAN in UTF8String with encoding of
>> matching rules; Regex SAN/IAN; Formalize security model; Sender does cert
>> lookup to find alternate address variant certificate;
>> * Note: large discussion by SMTP folks noted below in: Another attempt to
>> canonicalize local parts
>> * Drafts: draft-bhjl-x509-srv-00
>>
>>
>> Support for email address internationalization in RFC5280 certificates
>> * Start: 4 Feb 16
>> * Draft: draft-lbaudoin-iemax-02.txt (see also
>> draft-ietf-pkix-eai-addresses-00)
>> * Counter proposal: Consider instead redefining Rfc822Name as CHOICE
>> including UTF8String
>>
>>
>> key identities
>> * Start: 14 Mar 16 (from tmiller on: why you shouldn't even try to
>> canonicalize local parts)
>> * Proposal: Verify signature and cert path, TOFU the address FROM/SENDER
>> address and remember public key;  identify by public key SKID, subsequently
>> only verify the signature from the public key; Key roll over
>> * Issue: signing?; a priori discovery?; human comprehensible notion of
>> identity or name
>>
>>
>> Summary of S/MIME Problems/Issues
>> * Start: 11 Mar 16 (from mrex on: another attempt to canonicalize local
>> parts)
>> * Issues: Incomplete chains; Mail archival problems when certificates
>> expire i.e. revalidating signature or decryption due to MUA certificate and
>> timestamp management, and lack of help from CAs
>>
>>
>> Another attempt to canonicalize local parts: 3rd party interpretation of
>> email address local parts for validation or key discovery  is a bad idea
>> * Start: 11 Mar 16
>> * Issues: RFC5321 stats only MTA may interpret the local part; MUA UI
>> poorly does key management; “key structures” i.e. key discovery is difficult
>> * Proposal: Modernize email address to enable validation; IETF should get
>> into standardizing UI particularly for key management; Key discovery via
>> oracle
>>
>>
>> e2e email security (stephen farrell)
>> * Start: 12 Mar 16
>> * Issues: No MUA development; email environment is centralized; mail
>> headers not protected; e2e may prevent anti-spam technology
>> * Proposal: allow experimentation
>>
>>
>> Key lookup service via draft-bhjl-x509-srv-00
>> * Start 22 Mar 16
>> * Proposal: Use the draft for key lookup; provides means to do initial
>> certificate discovery; authoritative; certificate renewal; oracle for new
>> email name variants;
>> * Issues: Key management is hard; security risk for automated key
>> re-enrollment; security issues with a centralized key directory; handling
>> ownership of multiple mailbox;
>> * Draft: draft-bhjl-x509-srv-00
>>
>>
>> BCP proposal: regular expressions for Internet Mail identifiers
>> * Start: 22 Mar 16
>> * Proposal: Standardize regex for email addresses
>>
>>
>> S/MIME Mailing List
>>
>>
>> Message takeover attacks against S/MIME
>> * Start: 27 Jan 16
>> * Proposal: Adding authenticated encryption to S/MIME;
>> * Issues: S/MIME doesn’t keep headers private; MUA don’t understand
>> message/rfc822; attack via signed-then-encrypted message into
>> encrypted-then-signed using attackers identity and replies will leak the
>> original content
>>
>>
>> Is this enough to re-charter the S/MIME WG?
>> * Start: 8 Mar 16 (from housley on “Message takeover attacks against
>> S/MIME”)
>> * several folks willing to help; AEAD: AES-CCM, AES-GCM, ChaCha20-Poly1305;
>> domain signing; Curve25519 and Curve448, CFRG ECC curves;  automated cert
>> enrollment; protect mail headers; standardize on RFC5753  i.e.ECC away from
>> informational; updated RFC documentation e.g. RFC 4134; drop old ciphers
>> e.g. md5, sha1; prevent signature stripping attacks
>> * Draft: draft-melnikov-smime-msa-to-mda-04
>>
>>
>> General S/MIME issues / solutions
>> * Start: 29 Jan 16 (from phill on: Message takeover attacks against S/MIME)
>> * Proposal: merge PGP and S/MIME; publish consistent modern crypto suit in
>> CURDLE; make it work with WebMail; configuration must be painless
>>
>>
>> ---------- Forwarded message ----------
>> From: Stephen Farrell<[email-masked]>
>> Date: Thu, Mar 24, 2016 at 5:28 AM
>> Subject: Re: [pkix] possible new pkix and/or smime work
>> To: pkix<[email-masked]>
>>
>>
>>
>> I got a couple of volunteers, Wei Chuang and John Levine
>> (thanks both!) who're aiming to produce us a summary of
>> the recent list discussion we can ponder in a few days.
>>
>> Cheers,
>> S.
>>
>> On 23/03/16 20:35, Stephen Farrell wrote:
>>> Folks,
>>>
>>> I'm finding it hard to evaluate the discussion as to whether
>>> there's new work folks want to do here that'd justify forming
>>> a (coherent) WG and that'd result in likely implementation and
>>> deployment. I expect others may be similarly uncertain.
>>>
>>> Would someone be willing to volunteer to act in a slightly
>>> chair-like manner and try to summarise the discussion in a
>>> way that might help us judge the above?
>>>
>>> I think that might help us to e.g. organise a bit of a bar
>>> BoF or collective chat amongst those interested while a bunch
>>> of us are in B-A and on the list prior to that.
>>>
>>> Thanks,
>>> S.
>>>
>>> PS; If you are willing to do that but shy, feel free to send to
>>> me offlist and I can pretend I did the work:-)
>>>
>>>
>>>
>>>

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca