Subject: [Webpush] Call for Adoption : encryption draft as a WG item

From: Shida Schubert <[email-masked]>
Date: Tue, 8 Sep 2015 22:09:39 -0700

All, 

At the last meeting, we discussed the need for an encryption for web push protocol. 

There were some debates about moving the encryption draft written by Martin (draft-thomson-webpush-encryption-01) either as part of the core protocol draft or as a separate draft. 

I want to get a sense of the WG in adopting Martin’s draft as a baseline for WG draft, addressing the milestone of “web push encryption", with a target of a Product Standard. 

This draft will be submitted to IESG at the same time as the core protocol draft. 

Regards
 Shida

---

From: Brian Raymor <[email-masked]>
Date: Wed, 9 Sep 2015 23:55:27 +0000

Hi Shida,

Since draft-thomson-webpush-encryption-01 is dependent on draft-thomson-http-encryption-01, is the intent to liaison with HTTPbis at IETF 94 and request a mechanism for encrypted content-encoding? This would be similar to the request from HTTPbis to TLS to address next protocol negotiation at IETF 85 (Slide 7) - http://www.ietf.org/proceedings/85/slides/slides-85-tls-1.pdf.

...Brian

-----Original Message-----
From: Webpush [mailto:[email-masked]] On Behalf Of Shida Schubert
Sent: Tuesday, September 8, 2015 10:10 PM
To: [email-masked]
Subject: [Webpush] Call for Adoption : encryption draft as a WG item

All, 

Regards
 Shida
_______________________________________________
Webpush mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webpush

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Sep 2015 18:11:53 -0700

> Since draft-thomson-webpush-encryption-01 is dependent on draft-thomson-http-encryption-01, is the intent to liaison with HTTPbis at IETF 94 and request a mechanism for encrypted content-encoding?…

I think that would be best, though I'd suggest that our area directors
are the best people to consult on the distribution of work.  As it was
with ALPN, we give up change control when that happens and would have
to respect the decisions made with respect to that work as it evolves.
And even as I observe that we're shipping code that uses these
specifications - I think that is OK and realistically the only way
that this whole process is going to work properly.

On a separate point entirely, I'm currently considering whether adding
another key exchange method for the new curve25519 work that is about
to be published.  If this is adopted, then I will likely propose that
the working group consider defining how 25519 works, though I think it
could remain optional.  Some implementations will want to use 25519 if
it is available; some would want to use it even it were not :)  As
much as I don't like having too many choices, this option does less
harm than its potential advantages.

---

From: Brian Raymor <[email-masked]>
Date: Thu, 10 Sep 2015 21:40:05 +0000

>I think that would be best, though I'd suggest that our area directors are the best people to consult on the distribution of work.  As it was with ALPN, we give up change control when that happens and would have to respect the decisions made with respect to that work as it evolves.

Then, I'd prefer to keep encryption as an optional feature in a separate draft from the core protocol until there is more clarity. Have existing solutions also been completely ruled out? I did miss the earlier HTTPbis discussion at IETF 92 due to schedule conflicts. The tone/direction of the conversation is a bit hard to assess from the minutes.

...Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Sep 2015 15:13:03 -0700

On 10 September 2015 at 14:40, Brian Raymor <[email-masked]> wrote:
> Have existing solutions also been completely ruled out?

What existing solutions do you refer to?

I have no issue with this remaining separate, I thought that was the
outcome of the discussion last meeting and the updated milestones
corroborate that.

---

From: Brian Raymor <[email-masked]>
Date: Thu, 10 Sep 2015 22:29:51 +0000

>What existing solutions do you refer to?

Again, the IETF 92 minutes are ambiguous (perhaps I should listen to the audio), but it seemed like there was feedback from the audience of  the "What not X" sort? Is there consensus in httpbis for this approach now? 

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf92/minutes.md

encrypted content-encoding for http
mnot: working on this w/MT

mt: coupl use cases: webpush, need to push stuff thru intermediary, encrypt doc on server

mt: This is just a simple cut down version of tls record layer and some key mgmt

mt: there's some impls -- pretty interested in getting this going

mt: using jose didn't work in http semantics. eg a msg being processed continuously rather than a single blob

mt: no optionality in the format -- simple

mt: will engage w/sec folk

lm: there's desire afoot to secure http headers and optionally body and so ....

ph: why wont CMS w/smime eg smime 3 not work? pls engage smime list

mnot: so this spec is an fyi at this point

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Sep 2015 15:44:57 -0700

> ph: why wont CMS w/smime eg smime 3 not work? pls engage smime list

This happened.  I didn't get any strong signals of support, but I
didn't get anyone telling me that it was wrong when I explained why I
couldn't use CMS.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Sep 2015 10:16:15 -0400

Brian et al,

FWIW - I'm considering doing a Call for Adoption on that draft in the not-too-distant future, but haven't talked to Barry about it yet. 

That said, one of the factors that will help make that determination is this WG having a dependency on the work.

Cheers,

> On 10 Sep 2015, at 5:40 pm, Brian Raymor <[email-masked]> wrote:
> 
> 

--
Mark Nottingham   https://www.mnot.net/