Subject: [Lake] Alissa Cooper's Block on charter-ietf-lake-00-00: (with BLOCK)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 02 Oct 2019 17:33:28 -0700

Alissa Cooper has entered the following ballot position for
charter-ietf-lake-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-lake/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I have two questions I'd like to discuss before this goes out for external
review:

1. What are "the security properties expected of IETF protocols"? I think it
would be fair to conclude that different protocols have different security
properties. Is there a document to reference or some other way to convey what
is meant by this?

2. I'm a little unclear on the interaction between the "at most one" language
and the text about the TLS WG. If the TLS WG produces a LAKE that satisfies the
requirements that the LAKE WG specifies, would that count as the "one"? Or
might the TLS WG produce one and the LAKE WG produce one? Or is the TLS WG not
expected to work on a LAKE?

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Oct 2019 14:59:59 -0700

Hi Alissa,

Thanks for the close read.

> https://datatracker.ietf.org/doc/charter-ietf-lake/

This is probably my fault, as I suggested/added that line kind of at the
last minute.  Per
https://mailarchive.ietf.org/arch/msg/lake/3vXOjAUtkShaIhoAwzdnDAFlAkI ,
the idea is that "constrained" is not going to be an excuse to use bad
crypto, presumably in terms of the bit-strength of the confidentiality,
integrity, and authentication protections.  (I do note that we have quite a
bit of precedent for halving the integrity strength for IoT use to 64-bit
tags, but am not sure if I will come up with a good phrasing.)

> expected to work on a LAKE?

It's fair to ask for clarity here: my sense is that "at most one" applies
to protocols that are the output of the LAKE WG.  If there's one (or more)
technologies from other WGs that meet the requirements as well as one being
produced by a LAKE WG, that's something we'll have to be able to address as
it arises.  My sense is that the WG will have spent a bunch of time
thinking about the problem space, so I'd ask the WG to make a qualitative
assessment of which technology to select for OSCORE, which could be (e.g.)
something from TLS or the "in-house" product.  I acknowledge that there may
be a bias towards the "in-house" product, but am confident that arguments
for and against diversity of available technology will be presented and
considered as the chairs determine consensus.

I'll note that TLS would (IMO) need a recharter to work on a LAKE, which
would most likely be to produce a modified form of TLS that is not subject
to the requirement that it *be* TLS (i.e., negotiates with previous
versions), allowing for a lot of redundancy and inefficiencies to be
removed.  Full de novo protocol work seems like it would fit better
elsewhere.

I'll work on some text to try to clarify these points (and add LWIG to the
related WG list; thanks Éric!).

Thanks,
Ben