Minutes IETF101: secdispatch
minutes-101-secdispatch-00

Security Dispatch (Secdispatch) WG Minutes
IETF 101

Tuesday, March 20, 2018
9:30-12:00, Morning session I
Room: Blenheim (-3E)

Summary
=======
The following items were brought to the WG meeting and were dispatched as
follows:

** draft: draft-foudil-securitytxt-03 -- AD-sponsorship
** draft: draft-nir-saag-star-01 -- bring to the LAMPS WG
** draft-housley-cms-mts-hash-sig-08 -- bring to the LAMPS WG
** draft: draft-birk-pep-trustwords-00 -- describe scope/problem statement to
SAAG/SECDISPATCH mailing lists ** draft-friel-tls-atls-00 -- requires ART-SEC
AD discussion for next steps

1. Logistics and introduction (chairs, 10 min)
=============================
presenters: chairs
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-chairs-overview-02

The chairs introduced the Security Dispatch process.

Agenda bashing added draft-friel-tls-atls-00.

2. A Method for Web Security Policies (security.txt)
====================================================
draft: draft-foudil-securitytxt-03
presenter: Ed Foudil
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-a-method-for-web-security-policies-securitytxt-01

Foudil presented draft-foudil-securitytxt-03 and asked for a recommendation on
how to proceed.

Q: (Mark Nottingham) Is this already used?
A: (Foudil) Yes -- Google, Facebook, and others
A: (Nottingham)  Seems reasonable.  Good that there’s already adoption.  It
would not be appropriate for HTTP WG.

Q: (Ted) Would this format support multiple languages?
A: (Foudil) It does not.

Comment: (): Perhaps this should be made machine-readable too

Comment: (Daniel Gillmor) Nice and simple, support this.  Think about the scope
of the security: site vs project

Comment: (Phillip Hallam-Baker) I like it a lot.

Comment: (Cullen Jennings) I like it and recommend it should be AD sponsored. 
Don’t add languages; keep it simple.

Comment: (Paul W) Bad idea.  If web server is compromised, how can I trust
this?  We have other ways (RDAP/whois) to get this information outside the
(compromised) web site.

Comment: (Ben Kaduk) Perhaps this should be a small WG.

Comment: (Eric Rescorla) I appreciate the possible security problems, but
alternatives seem heavyweight.  I would not be opposed to small WG

Comment: (Yaron Sheffer) You seem undecided about whether the target is
machines or humans.  I18n matters more for humans; contact information may be
different. A: (Martin T) This is machine-readable format that contains URIs,
not i18n-able, not needed. A: (Joe H) Agreeing with Martin; it already says
UTF-8, and an administrator who cares can always put data in whatever
language(s).

Comment from chairs: Most feedback appears to be that this is a good idea.

[chairs] WG please hum on these options:
(1) this draft should be AD sponsored
(2) this draft should be a handled by a short-lived new WG
(3) do nothing with this draft

Consensus Outcome: recommendation for AD sponsorship

Dispatch result: recommendation for AD sponsorship

3. Considerations For Using Short Term Certificates
===================================================
draft: draft-nir-saag-star-01
presenter: Yoav Nir
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-considerations-for-using-short-term-certificates-00

Nir presented draft-nir-saag-star-01 and asked for a recommendation on how to
proceed.  The primary motivation for this draft was to discuss how to deal with
short-term certificates.

Q: (Hannes Tschofenig) Is this specific to ACME? (Intended as Informational);
ACME is an example of these types of certificates.

Comment: (Tim Hollebeek) Love this, but some of it’s over the top.  No reason
not to use it on the web, for instance.  We should discuss the challenges,
rather than dismiss them.

Comment: (Volker Birk) We’ve discussed this before and decided against it. If
keys expire quickly, you need new keys frequently. Mechanism for distributing
keys can also distribute revocation info.

Comment: (Phillip Hallam-Baker) Good reasons to use short-term certs on the
web.  Cloud systems, for example.  Key exposures.

Comment: (Eric Rescorla) Are you expecting communication from CA to client?

Comment: (Stefan S) Should be rescoped to revocationless certificate, not just
short-term; might be other reasons

Comment: (Melinda Shore) Might rethink the language around key reuse and renewal

Q: (Toma G) Is the focus on data centers?
A: (Nir) Yes.
A: (Toma G) Seems like you’re replacing CRL distribution with certificate
distribution.  Seems not to be making things better, really. (Reovcation server
needs to be up all the time, so it’s different.

Comment: (Phillip Hallam-Baker): This draft should not be AD sponsored. 
Perhaps a WG.  Challenge will be interfacing with CT.

Comment: (Russ Housley) I support the ability to flag these certificates as
non-revokable, but no ad-sponsorship on this draft.

Comment: (Eric Rescorla) I'm not sure how publication of this draft changes
anything; or helps tell security auditor why we don’t have revocation ability.

Dispatch result: bring to the LAMPS WG

4. Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the
Cryptographic Message Syntax (CMS)
========================================================================================================
draft: draft-housley-cms-mts-hash-sig-08
presenter: Russ Housley
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-use-of-the-hash-based-digital-signatures-in-the-cryptographic-message-syntax-draft-housley-cms-mts-hash-sig-08-00

Housley presented draft-housley-cms-mts-hash-sig-08 and asked for a
recommendation on how to proceed.

Comment: (Stephen F) I like the idea of work being done on this topic. Are you
looking at rolling over to next gen key?

Q: (Bob V) Are algorithms done?
A: (Housley): Yes.

Comment: () Prefer that this draft not be scoped to IoT, prefer starting a
post-quantum working group

Comment: (Phillip Hallam-Baker) I would prefer to see this would in LAMPS WG. 
It has significant connections to PKI stack.

Comment: (Eric Rescorla) I would prefer to see this would in LAMPS WG.  This is
important work.  I don’t think should create a post-quantum WG

Comment: (Cullen Jennings) I don’t think SUIT is a good choice

Comment: () Recharter or change names of lamps?  curdle?

Comment: (Eric Rescorla) Would you bring it to COSE?  It should be generic so
other groups can use beyond CMS. A: (David W.) +1 what EKR is saying

Dispatch result: bring to the LAMPS WG

5. pretty Easy privacy (pEp): Trustwords concept
================================================
draft: draft-birk-pep-trustwords-00
presenter: Birk Volker and Bernie Hoeneisen
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-trustwords-00

Volker and Hoeneisen presented draft-birk-pep-trustwords-00 and the broader pEp
construct; and asked for a recommendation on how to proceed.

Comment: (Phillip Hallam-Baker) I like it and am supportive.

Comment: (): I think that this problem is more complex that you think. 
Language translation is an issue for communications. A: (Volker) We avoid
translation.

Comment: (Martin T) You can pick many words with different connotations but
shouldn’t rely on humans to carry cryptographic dependencies A: (Volker) This
work tries to remove human dependencies.

Comment: (Jeffery R.) I like idea of standardizing word strings, but wish it
wasn’t limited to 65k words

Comment: (Dan G.) I agree about human dependencies, 16-bit isn’t sufficient for
most languages

Comment: (Joe Hildebrand) Representing the XMPP community, we're looking for
liaison to XMPP community with this work.

Q: (Eric Rescorla) Are you willing to bring all of PEP to IETF?
A: (Volker/Hoeneisen) We think so.  We see PEP as toolbox, and want to focus on
interoperability. A: (Eric Rescorla) This draft doesn’t define trustwords, just
the algorithms to determine them, do you plan to define the trustwords? A:
(Volker) We do plan to define trustwords in IANA.  If at the end it is just a
registry of words, may not be too interesting

Comment: (Phillip Hallam-Baker) You might want to look at making the registry
more general, perhaps supporting images.  65k word dictionary is much more than
most humans know

Comment: (Cullen Jennings) This should focus on problem we are trying to solve.
 This work is too complex for AD sponsorship.  Someone should write a
mini-charter for a proposed WG. A: (David ) +1 on this point

Comment: (Eric Rescorla) Maybe this work needs a mailing list for technical
discussions, if the entire scope is under consideration.

Dispatch result: describe scope/problem statement to SAAG/SECDISPATCH mailing
lists

6. Application Layer TLS
========================
draft: draft-friel-tls-atls-00
presenter: Owen Friel
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-atls-00

Friel presented draft-friel-tls-atls-00 and asked for a recommendation on how
to proceed.

Q: () Will this look like an HTTP tunnel?
A: (Owen Friel) This work solves a different problem than HTTP tunneling
A: (Daniel Gillmor) +1 for this, perhaps break up into the different things
this does into different WGs, too many different use-cases A: (Eric Rescorla)
We shouldn’t design in this meeting. Do people thing tunneling crypto info is
useful? I want a general end-to-end solution beyond HTTP, that covers all
protocols A: (Ben Kaduk) Sounds like this is ripe for BOF to figure out what
area this should go

Comment: (Richard Barnes) The point of this work is to create a secure way for
transporting security information within an application protocol A: (Eric
Rescorla) Proponents should get together to create BOF A: (Richard Barnes)
We're treating this like mini-WG for scope of work, but still do BOF

Comment: (Kathleen Moriarty): It may not need BOF.

Dispatch result: requires ART-SEC AD discussion for next steps