Web Cryptography Working Group Teleconference -- 12 Oct 2015

<trackbot> Date: 12 October 2015

<scribe> scribe: hhalpin

bal: The reason I dove onto this call to discuss CFRG's supposed output
... given recent Suite B announcements
... I've gotten lots of questions

virginie: We'd like Microsoft's input on implementing various algorithms
... in particular, RSA-PSS

Note last time Vijay said it wasn't likely for RSA-PSS to be implemented in WebCrypto soon

Note also I believe Israel has left Microsoft I heard?

So maybe ask Vijay?

bal: this will be my personal opinion, not a product commitment

<virginie> to hhalpin : yes, for israel leaving , heard too :)

I'd like to have a procedure for adding algorithms at the end of this meeting.

bal: We have less interoperability than we hoped for across a wide variety of algorithms
... for example, we're not seeing RSA-PSS implemented
... would polyfill count? We've shipped that.

<virginie> ACTION: hhalpin to clarify polyfill versus native in the implementation count [recorded in http://www.w3.org/2015/10/12-crypto-minutes.html#action01]

<trackbot> Created ACTION-153 - : clarify polyfill versus native in the implementation count [on Harry Halpin - due 2015-10-19].

I'm OK with a polyfill, but I'd have to check with W3C

bal: Again, new investiment is in Edge, so unclear how it will come.
... we aren't talking about a browser profile
... we're talking about two communicating points
... two Javascript implementations should count
... Note we've moved on, I don't have a lot of cycles
... if there's code out there, we can do that
... if we want it all to be native in the browser, that's fine

virginie: What are the chances that if something in polyfill becomes native in browser?

bal: We don't have an agreement between polyfill and the browser
... we had product groups inside of MS that needed this functionality
... we needed client side crypto and all they had was a browser context
... so we have a client base for library, but that's separate from the Windows browser

Sounds like a strong case for the polyfill, I'll ask PLH and W3C if they have any opinion

Discussion around transfer of algorithms to Note

Virginie: Some algorithms will be removed as they are not implemented in two different browsers

Note DH and AES-CTR are also implemented in Mozilla

virginie: If Mozilla can't ship in main browser, then we have to remove it.

PROPOSAL: We can keep it until a few days before, and then we remove it.

virginie: testing on nightly is OK?

hhalpin: Yes, it varies by working group

its OK in our case

but he really does want things without two interoperable implementions he wants removed

virginie: What should we do with these?
... NUMS and Curve 25519 were not reviewed extensively
... I would put past algorithms in one note and others a second note.

bal: My advice is not that's important for some of these algorithms
... they fail to meet interoperability minimum bar
... the text is present in the CR
... so we won't lose it.
... if we text of other algorithms in a spec
... it might confuse people
... it was also an issue with XML-DSIG
... the big lesson from XML-DSIG, was that to try to get SHA-2 into spec took us 4 years
... we needed all of Suite B
... two years of a IRTF WG hold
... it made spec be less relevant, not fast enough for industry
... we are going to see a lot more churn in proposed algorithms
... its going to happen on elliptic curve space, post-quantum space
... its hitting TLS

+1 keeping post-quantum in mind

scribe: I will assume you want a clear process
... and to keep people from submitting.
... There are certain national algorithms that may come here too.

virginie: Would you recommend one spec per algorithm?

bal: That might overload process of W3C

virginie: Removing the stuff is done, but we need to know what to do next.

bal: Let me throw a further wrench, we've had the 4Q curve that is 2.5 faster than Curve25519
... lots of interest in performance characteristics
... its always tough to register new algorithms
... in XML-DSIG you could define new identifier and we were loose with private labels
... none of this is mandatory to implement
... I've found Notes to have limited value

virginie: There is no plan to put them in our main spec
... the Note is algorithms be implemented

http://www.w3.org/2014/Process-20140801/#revised-cr

bal: If you say "Proposed" then it could be considered going forward
... if you say "Additional" then its less likely.
... I know there's lots of different opinions on the registry
... my feeling is we're going to see a lot more things proposed due to lots of new work
... its not going to be one or two

virginie: What is going to drive adoption is implementation
... it will be the implementation that reflects the market
... but maybe not so many implementations

bal: We'll need to try some things out
... what the engineering parameters will be.
... given NSA just killed P-256 by saying its not part of Suite B anymore
... thrown EC up in the air a bit
... so what's going on is we're going to be also reflecting what's happening this of.

"Submitted for Consideration"

bal: It will open it wide up, but not commitment no action

What about DH?

Should we have a third category

or do we put in "Proposed" or "Submitted"

bal: From our experience, theres clear wins on the ECDH side
... we need a motivating scenario

some crypto libraries let everything in

bal: So I would dump it back in Proposed
... unless you feel a negative recommendation

I would support putting DH into "Proposed"

and anything else the WG ha agreed on but hasn't - for whatever reason - been implemented.

hhalpin: We're going to ship rather than wait for the crypto-space to be stable

bal: Let's ship this

virginie: We'll be pragmatic
... and when someone proposes a new algorithm, we'll direct them to do it

hhalpin: And the only testing will be interop

bal: I think you're correct on that
... all national standards bodies are pushing for international standards via ISO
... for examples, these could go into "Proposed"

virginie: What about presence or absence of algorithms per region?
... that is something we'll have to deal with
... in order to stay pragmatic

bal: National-level interop and regional restrictions around crypto never came up in XML-DSIG
... what key lengths you were allowed etc.
... Not a problem I'd try to proactively solve
... if we start proactively adding support, we'll encourage fractured spaces
... doesn't help interop
... web and physical locality doesn't interact very well

- DRAFT -

Web Cryptography Working Group Teleconference

12 Oct 2015

Attendees

Contents

Discussion around transfer of algorithms to Note

Summary of Action Items

Scribe.perl diagnostic output