Minutes IETF106: secdispatch
minutes-106-secdispatch-00

Secdispatch - IETF106
Tuesday Nov 19 2019, (17:10-18:40)

Chairs: Francesca Palombini, Richard Barnes, Kathleen Moriarty (remote), Nancy
Cam-Winget (stand-in)

Minute takers:
Rich Salz,
Giridhar Mandyam

Recordings: https://www.youtube.com/watch?v=CYBhLQ0-fwE
Session's material: https://datatracker.ietf.org/meeting/106/session/secdispatch

1.  Logistics and introduction (chairs)
---------------------------------------
Intro and Note Well; welcome Francesca as new co-chair

2.  Problem statement for post-quantum multi-algorithm PKI (Max Pala)
---------------------------------------------------------------------
draft:  https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
        https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/

Intro:  will RSA/ECC fail?  Are Lattice schemes sufficiently strong?
        Can PKI's be secure in 20, 30 years?
        Different solutions:  multi-chain, ISARA Catalys, Composite Crypto

Multi-chain/Multiple Certs:
    Pro's:  Suitable for negotiated protocols
    Con's:  Require protocol changes for multiple signature validation, how
    would it work with non-negotiated protocols

Hybrid Certs:
        ITU-T added new extensions/rules for alternative sigs/keys.
    Pro's:  backwards-compatible
    Cons:  backwards-compatible (i.e. false sense of security)

Composite crypto: new public key algm.  Data structures defined to hold
keys/sigs use sequences of keys/sigs.
    Pro's:  "Drop-in" for existing OID-based crypto protocols, can be extended
    to combine algm.'s, can be used in all PKIX lifecycle stages Con's: 
    backwards-compatiblity requires support of new algm. ID's, large keys/sigs
    are sent every time even if they are not used

Discussion on secdispatch mailing list to problem statement I.-D. and composite
crypto solution have been mixed. Different approaches have been proposed (e.g.
MathMesh). TLS community has not chimed in yet.

Discussion

Perhaps not applicable to TLS, contrasted with signatures/off-line where it
seems more applicable. Skepticism as to value in Web PKI.  Browsers either
accept an algorithm or they don't; hybrid algorithms that could include
deprecated algorithms won't be possible for real-time applications. Max Pala:
this is useful for protection of high-value keys such as Root CA's. There was
additional skepticism expressed on use of hybrid crypto in a TLS context, as
TLS has tried to simplify signatures, and complexity may have to be pushed into
the crypto libraries. Chair suggest LAMPS; LAMPS sent it here.  Seems scoped to
signatures, so Secdispatch recommends to go back  to LAMPS.

Conclusion:
Chairs recommendation (to be confirmed on list):  dispatch to LAMPS.

3.  OCSPv2 - Improving OCSP Responses (Max Pala)
------------------------------------------------
LAMPS & PKIX discussions:

Ml discussion:
https://mailarchive.ietf.org/arch/msg/pkix/eGE53uJIYKSzu7pObiUGWNXDH3M
               https://mailarchive.ietf.org/arch/msg/spasm/Ug_HtJz5FQvLbiXIdGXH---q7N8

Problem statement:  revocation infrastructure is costly.  OCSP does not scale
well for large PKI. OCSP not optimized for the common case - "no revocation
information", i.e. cert is valid. In addition, the revocation information or
multiple certs in a chain can be simplified without multiple round trips. CRL's
and OCSP are the most common methods for cert revocation. CRL size is
unpredictable, unless statically partitioned. The proposal is to allow for
range queries to the PKI.  It allows for limited cert revocation information
requests from the client.

Discussion:

Much of the discussion was supportive.
There was discussion on whether CRL compression could be leveraged. If so,
maybe LAMPS could be of interest; maybe not change OCSP, but address narrowing
responses client needs to "hear". The ATSC example was mentioned, where
specific OCSP responses are stapled to the broadcast emission so that the
client can selectively download revocation information by tuning to the
associated channels. There was a question on how range requests could be used
when stapling is in effect. Another comment was it would be good to see data on
the "cost" of data currently have to send.

Conclusion:
Chairs recommendation (to be confirmed on list):  create a new focused working
group.

4.  Privacy Pass Protocol (Nick Sullivan)
-----------------------------------------
draft: https://datatracker.ietf.org/doc/draft-privacy-pass/

Privacy Pass is a zero-knowledge protocol suitable for use in large-scale
internet applications. The CAPTCHA example was cited, where a single CAPTCHA
provider may leak information if multiple websites are using it. Privacy Pass
provides a blind token from the CAPTCHA provider, and the client can unblind it
accordingly for future verifications. Blinded RSA was cited as an example. 
VOPRF is what is currently used, where the token is verified by the issuer.
Privacy Pass has FF and Chrome extensions over all Cloudlare sites. A proposed
Working Group charter was provided where a protocol would be defined such that
an auth token can be issued and verified in such a way as to blind the identity
of the user from the verifier, and use of the protocol in HTTPS.  ID Federation
is out-of-scope.

Discussion:

The offline authentication use case was suggested.
There was a question as to whether crypto work needed to be done as part of any
standardization effort. All discussion was supportive. Will collaborate, see
other uses. Want off-line added. Does CFRG need to review? Maybe. Suggest CFRG
review the crypto regardless. Reconsider "interop out of scope". Yes, maybe too
broad just federation out of scope. It was mentioned that cache/intermediary
interactions may require coordination with HTTPbis.

Conclusion:
Chairs Recommendation:  continue to work on possible charter text on the
mailing list.  A BoF could be next.

5.  HTTP Request signing (Justin Richer)
----------------------------------------
draft: https://tools.ietf.org/html/draft-cavage-http-signatures

Some driving use cases:  proof-of-possession, authentication, request message
integrity beyond TLS, non-repudiation, audit. HTTP message encapsulation breaks
layering, which is why it isn't done today.  HTTP messages are transformed, or
parsed by different entities and re-serialized. TLS message integrity/signing
does not work when traversing proxies or message relaying. S/HTTP encapsulates
HTTP in signed container, but it is not widely-used. JOSE wrapping could be
used to sign HTTP messages, but this looks like SOAP ("with curly braces").
Several standards were surveyed that propose some level of signing of HTTP
requests - Cavage, OAuth DPoP, OAuth PoP, XYZ project, and AWS v4. Cavage has
been published and used in several implementations, but it is not an IETF
standard. Proposal:  combine drafts, find a WG to take on this work, or start a
new WG.

Discussion:

It was suggested to bring this to HTTPbis.  mnot commented that the time may be
ripe to start the work, and could consider a call for adoption.  However, there
would need to be the appropriate crypto/security experts participating.
Integration with endpoints and intermediaries is tricky; may even be harder
than the crypto part. The speaker clarified that the Cavage authors are in
favor of IETF adoption

Conclusion:
Chairs Recommendation:  dispatched to HTTPBIS WG.

6.  Communication Network Perspective on Malware Lifecycle (Joachim Fabini)
---------------------------------------------------------------------------
draft: https://datatracker.ietf.org/doc/draft-fabini-smart-malware-lifecycle/

Discussion:

Chair - not clear how this fits into IETF, maybe the measurement stuff?
How does lifecycle model fit? Ans. maybe making RFC 3552 more resilient
not-yet-started IAB program on threat modelling might be a place for this.

Conclusion:
Chairs Recommendation:  check the IAB program (talk to Ted)

7.  Securing protocols between proxies and backend (HTTP?) servers (Brian
Campbell)
-----------------------------------------------------------------------------------
draft: Looking for support/contributors, no draft yet
--> needs draft

Conclusion:
Chairs Recommendation:  write up draft (can then re-submit to secdispatch)

8. 5m Wrap up, review of conclusions
------------------------------------
Summarized chairs recommendations.