Subject: [Secdispatch] LAKE next steps

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Aug 2019 10:50:07 -0500

Thank you to everyone who attended the LAKE BoF session! It was a
productive meeting that highlighted the community’s needs for work in this
space.  A key insight that emerged during the session was that there is a
fairly clear split between the “AKE for OSCORE” case and “general purpose
lightweight AKE” in terms of the set of requirements.  We are happy to note
a strong level of interest in a TLS-based solution that removes unnecessary
protocol fields and encoding redundancy, which has significant potential
for use in protocols that do not require traditional TLS cross-version
compatibility, in constrained and full-featured environments alike.
Likewise, we saw that the additional community engagement of a BoF was able
to provide new insights into the use cases and requirements for a LAKE [0],
both in the OSCORE and the more general case -- this is a great indication
of the value provided by the broad and cross-area IETF review process.

Based on the input received and energy in the room, we feel that it’s
appropriate to charter a WG to finish coalescing the requirements for the
OSCORE use case and evaluate solutions.  From we’ve seen so far, EDHOC
seems like the leading contender, especially with respect to the “reuse of
COSE algorithms” proposed requirement, but we of course welcome further
data (such as on the relative code footprint of core cryptographic
primitives vs. protocol integration for COSE/cTLS/etc.).

We also feel that it’s appropriate to find a home for work on cTLS to come
to fruition.  As noted during the BoF, this presents a multifaceted
problem, with input needed from TLS experts as to which parts of the
protocol are legacy artifacts vs. cryptographically necessary, and also
with input needed from domain experts on constrained devices as to which
protocol features are necessary and where to fall on the spectrum of
tradeoffs between fully general/full-featured and a stripped-down,
bare-bones feature set.  On the balance, though, it seems that discussion
of a general-purpose-but-compact TLS would be most effectively done in the
TLS WG with additional input and collaboration as needed.  We plan to ask
the TLS WG if there is interest in rechartering to take on this
“constrained TLS” work item (and we note that this includes thinking about
whether it is best done as a standalone specification or a “patch” or
“filter” to stock TLS that could apply to multiple TLS versions).

For the sake of facilitating discussion, we include draft charter text for
the OSCORE case, modified based on input from the BoF from the version that
was previously sent to secdispatch@ietf:

==[ CHARTER ]==
Problem

Constrained environments using OSCORE in network environments such as
NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key
exchange (LAKE) that enables forward security.  'Lightweight' refers to:

  * resource consumption, measured by bytes on the wire, wall-clock time to
    complete, or power consumption
  * the amount of new code required on end systems which already have an
    OSCORE stack

Goals

This working group is intended to be a narrowly focused activity
intended to produce at most one LAKE for OSCORE usage and close.

The working group will collaborate and coordinate with other IETF WGs
such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the
requirements and solution.  The WG will also evaluate work from
the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.

Program of Work

The deliverables of this WG are:

1. Design requirements of the lightweight authenticated key exchange
protocol for OSCORE (this draft will not be published as an RFC but will be
used to drive WG consensus on the deliverable (2)

2. Specify a lightweight authenticated key exchange protocol suitable for
use in constrained environments using OSCORE
==[ CHARTER ]==

Thanks,

Ben and Roman

[0]  For example, the total number of key exchange operations expected to
be performed over the lifetime of the device, as might be compared against
the total lifetime energy budget; and a request to make explicit what had
previously been implicit assumptions about the cost of various operations
(on various axes).

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Aug 2019 12:13:18 -0400

Hi Ben:

 From the discussion at the LAKE BoF, it seemed there was strong support 
[1] for also tackling the broader scenario (triggered by David Thaler's 
suggested dichotomy at the microphone).

I have some trouble seeing suggested next steps on tackling this broader 
problem in you email below. If you could elaborate on how you see this 
broader topic ("general purpose lightweight AKE") find a home in terms 
of next steps, that would be great. (In my mind, this is not simply "TLS 
with compressed representation".)

Best regards, Rene

[1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]):
Is OSCORE Key exchange a ('the narrow') problem that needs being solved?
strong on yes, none on negative question
Is broader constrained scenario a problem that needs solving?
strong on yes, low on no

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Göran Selander <[email-masked]>
Date: Thu, 22 Aug 2019 13:27:49 +0000

Hi Ben and Roman, 

If I understand right, the proposal is - in one sentence - to work both on a lightweight authenticated key exchange for OSCORE in the LAKE WG, and on a compact variant of TLS in the TLS WG. This sounds like a good way forward, since an optimal solution to one of the problems is most likely not optimal (or even suitable) for the other, and optimization is one of the reasons for doing this work in the first place.

The proposed charter looks fine, I only have one comment on the text, see below. In particular I don't think there is any need to further detail requirements in the charter since those can be agreed with the listed stakeholders as part of the work.

Excerpt from proposed charter:

'The working group will collaborate and coordinate with other IETF WGs
such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the
requirements and solution.  The WG will also evaluate work from
the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.'

My comment is on the last sentence above. I already commented on this sentence in a previous draft of the charter:
https://mailarchive.ietf.org/arch/msg/secdispatch/xJTkOA6zfU0TcQPMYevg8IBUSVk

Additionally, I don't think this sentence well reflects the text in your mail:

'From we’ve seen so far, EDHOC seems like the leading contender, especially with respect to the “reuse of COSE algorithms” proposed requirement, but we of course welcome further data (such as on the relative code footprint of core cryptographic primitives vs. protocol integration for COSE/cTLS/etc.).'

Detailed comments:
1. It is fine that the WG also evaluates work from the TLS WG, with the obvious restriction that only solutions that are ready and complies with the requirements need to be evaluated. As long as we agree on that, there is no need to change the charter on this point. 
2. Please move ", and draft-selander-ace-cose-ecdhe" from this sentence and include it in a sentence before this one indicating that it is currently the only specified AKE for OSCORE. 

Thanks
Göran

On 2019-08-20, 17:50, "Lake on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    

    ==[ CHARTER ]==
    Problem

    
    Goals

    
    Program of Work

    
    
    Thanks,
    
    Ben and Roman

    -- 
    Lake mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lake

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Aug 2019 15:24:31 -0500

> with compressed representation".)

I think we also heard, in addition to the generic "broader problem" hum,
several explicit statements at the mic about how a reduced-encoding
"compact TLS" was a good thing, and that having the LAKE discussions may
have been the trigger needed to make that happen.  So yes, my thinking was
mostly "TLS with compressed representation" and possibly some additional
tweaks that are TBD.  Could you elaborate on your thinking for how the
general-purpose lightweight AKE would differ from "TLS with compressed
representation"?

Thanks,

Ben

---

From: Rene Struik <[email-masked]>
Date: Mon, 26 Aug 2019 23:21:06 -0400

> general-purpose lightweight AKE would differ from "TLS with compressed

RS>> (Procedural.) I reread the draft minutes of the LAKE BoF and found 
15-17 hands for OSCORE and 10-11 for the general case (i.e., both have 
sufficient critical mass). Enthusiasm for other options was not polled 
in the room; hence, my question. You seem to quote Carsten Bormann's 
remark at the mic (according to minutes), but there were many other 
remarks as well, and - arguably - one can cherry-pick any set of remarks 
to arrive at different conclusions. The chartering discussion itself, 
though, did focus on the "narrow" vs. "general" notion David Thaler 
brought to the table and which was discussed in the latter part of the 
BoF meeting. BTW - I still do not understand how TLS with a compressed 
encoding scheme could be considered general. <<RS

RS>> (Technical.) It would be prudent for IETF not to put too many eggs 
in the same basket and, thereby, not have most protocols share the same 
crypto design philosophy, protocol flow framework, and instantiation. 
While arguably convenient, this is contrary to algorithm agility 
requirements (since results in in-tandem vulnerabilities and easily 
ossified code). Hence, my case for not loosing sight of addressing the 
more general problem, with an open mind. I am willing to contribute to 
this and so are 10 others (according to the hum). Arguably, this general 
case cannot presume the Client/Server model, nor semi-infinite resources 
on one of the entities. This being said, this is not a blank slate area 
and closure on fundamental design can be reached in a reasonable, 
limited time frame by experienced people. <<RS

>> Is OSCORE Key exchange a ('15-the narrow') problem that needs being solved?

[added from minutes]

Willing to work on documents - comment, review, etc.
- 15-17 hands for OSCORE
- 10-11 hands for the general case
- Few overlapping.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Aug 2019 19:44:32 +0300

Hi, Rene

> On 27 Aug 2019, at 6:21, Rene Struik <[email-masked]> wrote:
> 
> 
> RS>> (Technical.) It would be prudent for IETF not to put too many eggs in the same basket and, thereby, not have most protocols share the same crypto design philosophy, protocol flow framework, and instantiation. While arguably convenient, this is contrary to algorithm agility requirements (since results in in-tandem vulnerabilities and easily ossified code). 

I disagree with this.  It is not the IETF that is putting many eggs in one basket, but the market. It is the market that is protecting every piece of privacy-sensitive information using TLS: financial transaction, bank statements, credit cards, school transcripts, medical appointments and test results, email in transit to name but a few.

If TLS is compromised, all of that is compromised, and the fact that SSH or IPsec or some new OSCORE thing exist does not help me or anyone else whose personal information is now exposed.  If TLS is compromised we’ll have to fix TLS.  So regardless of what we decide at the IETF, a whole lot of our eggs are already in one basket. It’s a better use of our resources to make sure that basket is protected than to spend them on making a new basket that hardly anyone will use.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Aug 2019 16:22:55 -0400

On Tue, Aug 27, 2019 at 12:46 PM Yoav Nir <[email-masked]> wrote:

> RS>> (Technical.) It would be prudent for IETF not to put too many eggs in
> the same basket and, thereby, not have most protocols share the same crypto
> design philosophy, protocol flow framework, and instantiation. While
> arguably convenient, this is contrary to algorithm agility requirements
> (since results in in-tandem vulnerabilities and easily ossified code).
>
>
> I disagree with this.  It is not the IETF that is putting many eggs in one
> basket, but the market. It is the market that is protecting every piece of
> privacy-sensitive information using TLS: financial transaction, bank
> statements, credit cards, school transcripts, medical appointments and test
> results, email in transit to name but a few.
>
> If TLS is compromised, all of that is compromised, and the fact that SSH
> or IPsec or some new OSCORE thing exist does not help me or anyone else
> whose personal information is now exposed.  If TLS is compromised we’ll
> have to fix TLS.  So regardless of what we decide at the IETF, a whole lot
> of our eggs are already in one basket. It’s a better use of our resources
> to make sure that basket is protected than to spend them on making a new
> basket that hardly anyone will use.
>

My problem with using the TLS exchange is that we are still doing key
exchange using a signature for authentication like we did in SSL when the
whole protocol was predicated on use of RSA.

We have got rid of the RSA but we still demand that we use a signature to
authenticate the exchange which means that we leave non-repudiable evidence
that an exchange took place. Maybe not significant in TLS (I think it is
though) but certainly a concern in other areas.

There is another approach which is to make the exchanged secret dependent
on the supplemental information that we want to authenticate. So that the
key exchange will succeed if and only if both sides get the same
information. I believe this is what is done in Signal.

---

From: Rene Struik <[email-masked]>
Date: Tue, 27 Aug 2019 17:32:31 -0400

Hi Yoav:

To my knowledge, IETF prides itself of acting through the efforts of 
gifted individuals, who contribute their expertise and insights, and 
(hopefully) act in the interest of the [admittedly abstract notion of] 
the common good, and not with malicious intent. Mr. Market (whoever he 
or she is) does not sign blue sheets or stand at the mike; nor does the 
"invisible hand" show up in the authors' list or can it be held 
accountable for its actions. People do.

The point of my comment on agility was not so much that one could not 
end up with a TLS-like protocol (this is indeed possible and it is clear 
that some actors have ideas here), but that it should not be the 
pre-condition, esp. since the characteristics of lightweight 
applications might very well be different than those of TLS (e.g., with 
respect to real-life attacks, privacy, deployment, and control). The 
main point, thus, was to keep an open mind.

I am happy to accept a friendly amendment of my note and remove [for 
IETF] from the phrase "It would be prudent [for IETF] not to put many 
eggs in the same basket". I hope that helps and makes this a statement 
that should be obvious to anyone with technical inclinations (but 
nevertheless worth repeating).

Best regards, Rene

On 8/27/2019 12:44 PM, Yoav Nir wrote:
> Hi, Rene
>
>> On 27 Aug 2019, at 6:21, Rene Struik <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> RS>> (Technical.) It would be prudent for IETF not to put too many 
>> eggs in the same basket and, thereby, not have most protocols share 
>> the same crypto design philosophy, protocol flow framework, and 
>> instantiation. While arguably convenient, this is contrary to 
>> algorithm agility requirements (since results in in-tandem 
>> vulnerabilities and easily ossified code).
>
> I disagree with this.  It is not the IETF that is putting many eggs in 
> one basket, but the market. It is the market that is protecting every 
> piece of privacy-sensitive information using TLS: financial 
> transaction, bank statements, credit cards, school transcripts, 
> medical appointments and test results, email in transit to name but a few.
>
> If TLS is compromised, all of that is compromised, and the fact that 
> SSH or IPsec or some new OSCORE thing exist does not help me or anyone 
> else whose personal information is now exposed.  If TLS is compromised 
> we’ll have to fix TLS.  So regardless of what we decide at the IETF, a 
> whole lot of our eggs are already in one basket. It’s a better use of 
> our resources to make sure that basket is protected than to spend them 
> on making a new basket that hardly anyone will use.
>
> Yoav
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Aug 2019 15:46:42 -0500

[Note: secdispatch@ to bcc]

Hi Göran,

> https://mailarchive.ietf.org/arch/msg/secdispatch/xJTkOA6zfU0TcQPMYevg8IBUSVk

Oops, I'm sorry I didn't notice the comment from the previous round, when
preparing this draft text.  Are you proposing to just drop the "and
derivatives thereof"?  I believe that the intent last time around was to
include what became cTLS, though at that time it was unclear what home
could be found for it.  At this point it looks more likely like the TLS WG
could do it, though it's not decided for sure, so the cross-WG dependencies
remain a little annoying.  That said, I think that the proposed LAKE
charter should only consider output from the TLS WG, not
work-still-in-progress at the point when a decision is to be made.

> 'From we’ve seen so far, EDHOC seems like the leading contender, especially with respect to the “reuse of COSE algorithms” proposed requirement, but we of course welcome further data (such as on th…

That was intended to be my personal take, not an attempt to judge community
consensus.  (Well, Roman seems to have signed off on it, too, but the two
of us do not a community make.)  So the draft charter text was
intentionally more open.

> 1. It is fine that the WG also evaluates work from the TLS WG, with the obvious restriction that only solutions that are ready and complies with the requirements need to be evaluated. As long as we…

Right.  "Passed WGLC" is probably a usable threshold.

> 2. Please move ", and draft-selander-ace-cose-ecdhe" from this sentence and include it in a sentence before this one indicating that it is currently the only specified AKE for OSCORE. 

Recent IESGs have been somewhat fussy about the language used to describe
individual drafts in WG charters -- language like "evaluate" or "use as a
starting point" tends to do better than "will adopt" or similar.  And of
course it would be good to get some more feedback from the group, since
you're an author :)

Thanks,

Ben

> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Aug 2019 11:50:23 -0500

[secdispatch@ again to bcc]

Hi Rene,

> encoding scheme could be considered general. <<RS

I fear I'm still confused or don't understand your point, or perhaps what
you mean by "general".  Would you disagree if I said that "TLS is the de
facto general-purpose communications security protocol for the Web"?  What
about if I replaced "Web" with "Internet"?  If the core protocol is
general-purpose, does it not remain general-purpose if the encoding is
compressed?  The best way I can find to interpret your remark is that the
"general-purpose constrained use case" has different requirements than an
Internet-wide general-purpose communications protocol, but (1) I'm not very
confident that's what you mean, and (2) even if that is what you mean, I
don't know that anyone has tried to do a survey for what those specific
requirements would be and how they might differ from the Internet case.

> limited time frame by experienced people. <<RS

I actually do not take it as a given that, when working with a fixed set of
resources, diversity of design/implementation is always the most optimal
approach, regarding "eggs in the same basket" -- there are tradeoffs to be
made and the analysis may produce different results in different
situations.

With respect to your request to not lose sight of addressing the more
general problem, I note that the current charter under discussion is
explicitly targetting just the OSCORE use case, with intent to ask the TLS
WG to consider cTLS.  If you feel that this is not adequately addressing
what you see as the "more general problem", then please suggest an
alternate course of action, whether that is an edit to the proposed LAKE
charter, a draft charter for a separate WG, or some other proposal.  As it
is, I have to guess what you want to see happen, and my track record for
guessing is not great.

Thanks,

Ben