Subject: [TLS] integrity only ciphersuites

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 20 Aug 2018 20:48:03 +0000

All,
A couple IoT consortiums are trying to embrace the improvements made to TLS 1.3 and as they define their new security constructs would like to adopt the latest protocols, in this case TLS 1.3.   To that extent, they have a strong need for mutual authentication, but integrity only (no confidentiality) requirements.

In following the new IANA rules, we have posted the draft https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00 to document request for registrations of HMAC based cipher selections with TLS 1.3…..and are soliciting feedback from the WG on the draft and its path forward.

Warm regards, Nancy (and Jack)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Aug 2018 13:57:58 -0700

On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
ncamwing=[email-masked]> wrote:

> All,
>
> A couple IoT consortiums are trying to embrace the improvements made to
> TLS 1.3 and as they define their new security constructs would like to
> adopt the latest protocols, in this case TLS 1.3.   To that extent, they
> have a strong need for mutual authentication, but integrity only (no
> confidentiality) requirements.
>
>
>

> In following the new IANA rules, we have posted the draft
> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
> to document request for registrations of HMAC based cipher selections with
> TLS 1.3…..and are soliciting feedback from the WG on the draft and its path
> forward.
>

Nancy,

As you say, you don't need WG approval for code point registration as long
as you don't want Recommended status.

With that said, I don't think this document makes a very strong case for
these cipher suites. Essentially you say:

1. We don't need confidentiality
2. Code footprint is important

Generally, I'm not very enthusiastic about argument (1). It's often the
case that applications superficially need integrity but actually rely on
confidentiality in some way (the obvious case is that HTTP Cookies are an
authentication mechanism, but because they are a bearer token, you actually
need confidentiatilty). It's much easier to just always supply
confidentiality than to try to reason about when it is or is not needed.

The second argument is that you are trying to keep code size down. It's
true that not having AES is cheaper than having AES, but it's possible to
have very lightweight AES stacks (see for instance:
https://github.com/01org/tinycrypt).

So, overall, this doesn't seem very compelling.

-Ekr

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

---

From: Jack Visoky <[email-masked]>
Date: Mon, 20 Aug 2018 21:36:03 +0000

Hi Eric,

Thanks for your feedback.  Just a few points to add:

1. There really are some applications where confidentiality isn’t important, for example some motion control that might involve very simple move instructions (e.g. go to X, go to Y, go to Z, repeat).  Certainly there are also applications that would benefit from confidentiality, but there’s a non-trivial amount that really gain little to nothing.
2. In some cases the code size is quite important.  It’s not uncommon for hardware to be in the field in Industrial Automation for 15 or more years, so in some cases the hardware is already stretched pretty thin and might not be able to handle the demands of encryption.  At the same time it is hugely beneficial to take advantage of the security of TLS for many of these installations.
3. Another use case for these NULL encryption suites is around inspection of data.  I think this has been discussed in this forum already, but these cipher suites could support that as well.

Thanks and Best Regards,

Jack Visoky
Security Architect and Sr. Project Engineer
Common Architecture and Technology Group
Rockwell Automation | 1 Allen-Bradley Drive | Mayfield Heights, OH 44124

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, August 20, 2018 4:58 PM
To: Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>
Cc: [email-masked]
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites

[Use caution with links & attachments]

On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]> wrote:
All,
A couple IoT consortiums are trying to embrace the improvements made to TLS 1.3 and as they define their new security constructs would like to adopt the latest protocols, in this case TLS 1.3.   To that extent, they have a strong need for mutual authentication, but integrity only (no confidentiality) requirements.  

Nancy,

As you say, you don't need WG approval for code point registration as long as you don't want Recommended status.

With that said, I don't think this document makes a very strong case for these cipher suites. Essentially you say:

Generally, I'm not very enthusiastic about argument (1). It's often the case that applications superficially need integrity but actually rely on confidentiality in some way (the obvious case is that HTTP Cookies are an authentication mechanism, but because they are a bearer token, you actually need confidentiatilty). It's much easier to just always supply confidentiality than to try to reason about when it is or is not needed.

The second argument is that you are trying to keep code size down. It's true that not having AES is cheaper than having AES, but it's possible to have very lightweight AES stacks (see for instance: https://github.com/01org/tinycrypt).

So, overall, this doesn't seem very compelling..

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Aug 2018 15:29:20 -0700

On Mon, Aug 20, 2018 at 2:36 PM, Jack Visoky <[email-masked]>
wrote:

> 1. There really are some applications where confidentiality isn’t
> important, for example some motion control that might involve very simple
> move instructions (e.g. go to X, go to Y, go to Z, repeat).  Certainly
> there are also applications that would benefit from confidentiality, but
> there’s a non-trivial amount that really gain little to nothing.
>

Why do you think this isn't sensitive information? I can imagine scenarios
where it's not, but it also might be, as, for instance, it leaks the level
of activity of the device.

2. In some cases the code size is quite important.  It’s not uncommon for
> hardware to be in the field in Industrial Automation for 15 or more years,
> so in some cases the hardware is already stretched pretty thin and might
> not be able to handle the demands of encryption.  At the same time it is
> hugely beneficial to take advantage of the security of TLS for many of
> these installations.
>

This seems not very specific. Can you provide some actual numbers for the
difference in code size to have encryption as a fraction of the total code
size?

> 3. Another use case for these NULL encryption suites is around inspection
> of data.  I think this has been discussed in this forum already, but these
> cipher suites could support that as well.
>

Supporting this use case is not really a priority for this WG. In fact,
it's part of why we removed these ciphers in TLS 1.3.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 18:47:15 -0400

> hugely beneficial to take advantage of the security of TLS for many of

Given that you work for Rockwell, I'm assuming that you have specific
devices in mind, that these devices are already in the field, and that you
intend to upgrade their firmware to support CORE or something like that.
 Is this the use case you're talking about?

> cipher suites could support that as well.

I would really encourage you to take a look at MUD (Manufacturer Usage
Description) <https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/> as a
way to configure these devices.   I presume that the use case here is that
you have a device that could be pwned, and you want to be able to see what
it is sending.   But really it shouldn't even be having the conversation,
right?   MUD lets you configure your firewall automatically, preventing the
device, if it's pwned, from talking to the controlling botnet.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 20 Aug 2018 23:01:25 +0000

I tend to think the strongest scenario for integrity-only ciphersuites is in an application where the data being transferred is already encrypted sufficiently.  For example, when running IPsec over an IP-HTTPS tunnel, Microsoft used a null cipher on the outer TLS layer.  However, as you say, this can be deceptive.  DRM-protected media is already encrypted and seems like another application for this, but using TLS means it is not (as) trivial to identify that different flows are retrieving the same resource.

From: TLS <[email-masked]> On Behalf Of Eric Rescorla
Sent: Monday, August 20, 2018 1:58 PM
To: Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] integrity only ciphersuites

On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]<mailto:ncamwing=[email-masked]>> wrote:
All,
A couple IoT consortiums are trying to embrace the improvements made to TLS 1.3 and as they define their new security constructs would like to adopt the latest protocols, in this case TLS 1.3.   To that extent, they have a strong need for mutual authentication, but integrity only (no confidentiality) requirements.

Nancy,

-Ekr

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 20 Aug 2018 23:13:31 +0000

Hi Eric,
Thanks for the prompt feedback!  Please see further comments/questions below:

From: Eric Rescorla <[email-masked]>
Date: Monday, August 20, 2018 at 13:58
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] integrity only ciphersuites

Nancy,

Generally, I'm not very enthusiastic about argument (1). It's often the case that applications superficially need integrity but actually rely on confidentiality in some way (the obvious case is that HTTP Cookies are an authentication mechanism, but because they are a bearer token, you actually need confidentiatilty). It's much easier to just always supply confidentiality than to try to reason about when it is or is not needed.
[NCW] We are working diligently in several IoT based consortiums to begin to define security around those protocols as many today do not afford any protection at all.  At minimum, we want to ensure there is mutual authentication and authorization as well as message integrity.  As we cite in the draft, many “things” perform repetitive tasks that want to communicate motion, speed or other machine control functions that are not deemed to be private.
I can see your point/belief that it is much easier to include confidentiality, but some chipsets today especially at those levels (and cost) are not constructed with those provisions today, though they do have HMAC capabilities.

The second argument is that you are trying to keep code size down. It's true that not having AES is cheaper than having AES, but it's possible to have very lightweight AES stacks (see for instance: https://github.com/01org/tinycrypt).
[NCW] So, it is not just about code size, but overall hardware availability and cost….

-Ekr

---

From: Judson Wilson <[email-masked]>
Date: Mon, 20 Aug 2018 16:39:12 -0700

How are these devices authenticating?

On Mon, Aug 20, 2018 at 4:14 PM Nancy Cam-Winget (ncamwing) <ncamwing=
[email-masked]> wrote:

> *From: *Eric Rescorla <[email-masked]>
> *Date: *Monday, August 20, 2018 at 13:58
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
>
>
> *Subject: *Re: [TLS] integrity only ciphersuites
>
>
>
>
>
>
>
> [NCW] We are working diligently in several IoT based consortiums to begin
> to define security around those protocols as many today do not afford any
> protection at all.  At minimum, we want to ensure there is mutual
> authentication and authorization as well as message integrity.  As we cite
> in the draft, many “things” perform repetitive tasks that want to
> communicate motion, speed or other machine control functions that are not
> deemed to be private.
>
> I can see your point/belief that it is much easier to include
> confidentiality, but some chipsets today especially at those levels (and
> cost) are not constructed with those provisions today, though they do have
> HMAC capabilities.
>
>
>

---

From: Geoffrey Keating <[email-masked]>
Date: 20 Aug 2018 16:45:43 -0700

"Nancy Cam-Winget \(ncamwing\)" <ncamwing=[email-masked]> writes:

> to document request for registrations of HMAC based cipher
> selections with TLS 1.3…..and are soliciting feedback from the WG on
> the draft and its path forward.

This draft needs more security analysis than is currently there, and
probably it needs to define not just a ciphersuite but an entire
profile for using TLS with this ciphersuite.  Some topics:

* Anything that relies on EncryptedExtensions should probably not be
used.

* The session ticket properties change in the absence of encryption.  In
existing TLS 1.3, they are sent only after Finished and so are
encrypted; now they are public.  I am not sure if this changes the
security model but it definitely makes it easier to attack the ticket.

* A less-obvious consequence to the lack of confidentality is that a
typical implementation, an attacker can selectively block messages
knowing their contents (by breaking the connection).  In the weather
example this might be used to manipulate average daily temperature by
blocking only higher or only lower readings.  In the robot example
this might be used to cause it to exceed its limits by allowing
movement commands only in one direction.

I wonder whether it's really helpful to call the result 'TLS' and
not something else?

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 20 Aug 2018 16:59:17 -0700

There is one other -- admittedly esoteric! -- place where a NULL
cipher would he useful: Amateur Radio applications.

By law, we are forbidden from transmitting encrypted traffic, yet
there are use cases where integrity protection in the absence of
data content protection would be of benefit.

A very common case is controlling a remote repeater site.  Using
data integrity coupled with a client X.509 certificate means I can
restrict access to the "control" service at the site.  It's fine
if people see the traffic in flight, since they won't be able to
authenticate to do a replay or issue their own commands.

This is a distinct improvement over existing control schemes, which
typically use DTMF touch tone commands that anyone can trivially
figure out.

As I said, a very niche case.  It has been done before, using IPsec
AH, but that's extremely heavy weight, and a pain to configure and
maintain.  It also requires a full-on IP fabric, whereas TLS can
be implemented directly on top of AX.25 sessions, which represent
the vast majority of amateur radio packet data links (which I
acknowledge puts this outside the realm of the Internet, and therefore
the IETF).

--lyndon  (VE7TFX)

---

From: Judson Wilson <[email-masked]>
Date: Mon, 20 Aug 2018 17:17:15 -0700

FWIW HAM might require public key signing rather than MACs, since MACs are
meaningless without a key.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 21 Aug 2018 04:20:17 +0000

Lyndon Nerenberg <[email-masked]> writes:

>By law, we are forbidden from transmitting encrypted traffic, yet there are
>use cases where integrity protection in the absence of data content
>protection would be of benefit.

I've worked a lot with a set of authentication-only channels that can't be
encrypted but need strong integrity/authenticity protection.  The way to deal
with this is signed/MAC'd messages, not NULL-cipher TLS.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Aug 2018 00:32:16 -0400

> On Aug 20, 2018, at 4:57 PM, Eric Rescorla <[email-masked]> wrote:
> 

There is also a use-case for communication between processes on the same
machine, e.g. over unix-domain sockets and the like.  Encryption in this
context is pointless.  TLS can be used with client certificates as a means
of client authentication.

Postfix supports eNULL ciphers for unix-domain socket LMTP communication.
This works with TLS <= 1.2, but would require enabling unnecessary encryption
with TLS 1.3.

  http://www.postfix.org/TLS_README.html#client_tls_levels

  NOTE: Opportunistic encryption of LMTP traffic over UNIX-domain sockets
  or loopback TCP connections is futile. TLS is only useful in this context
  when it is mandatory, typically to allow at least one of the server or the
  client to authenticate the other. The "null" cipher grade may be appropriate
  in this context, when available on both client and server. The "null" ciphers
  provide authentication without encryption.

-- 
	Viktor.

---

From: Judson Wilson <[email-masked]>
Date: Mon, 20 Aug 2018 22:41:20 -0700

Inventing your own null cipher security opens up the door for replay,
withhold and reorder styles of attacks.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Aug 2018 12:41:36 +0100

On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote:
> All, A couple IoT consortiums are trying to embrace the improvements
> made to TLS 1.3 and as they define their new security constructs
> would like to adopt the latest protocols, in this case TLS 1.3.   To
> that extent, they have a strong need for mutual authentication, but
> integrity only (no confidentiality) requirements.
> 
> to document request for registrations of HMAC based cipher selections
> with TLS 1.3…..and are soliciting feedback from the WG on the draft
> and its path forward.

As ekr pointed out, with the new registration rules,
there's nothing to stop someone defining any old set
of crypto stuff and getting non-recommended codepoints.

That said, I don't consider that defining such
vulnerable-by-design ciphersuites is a good plan.

- It imposes costs on the non-niche users of TLS - once
these things are defined then developers and those who
deploy/configure applications using TLS need to check
that they're not using these undesirable ciphersuites,
so costs are being displaced from niche uses to the
vast majority of implementations and deployments, which
seems to me to be a bad idea. And we know that people
will sometimes get those checks wrong leading to unexpected
transmission of plaintext over the Internet.

- Similarly, just defining such ciphersuites seems likely
to lead to less well tested and infrequently used code
paths, which is undesirable. (Assuming someone pays some
developer to add these to some library, which generally
does seem to happen.)

- RFC7525 [1] is clear on this topic (after debate in the
UTA WG) - "Implementations MUST NOT negotiate the cipher
suites with NULL encryption" and I see nothing new to
convince me that that ought change for TLS1.3.

- Code footprint arguments aren't that convincing to
me - to get interop for the few devices where AES being
present or absent could make a real difference, you'd
need an awful lot more profiling of TLS or DTLS. I don't
see evidence of that so the interop/footprint arguments
seem pretty weak. I'd also bet that any useful "tiny
footprint" profile of that kind would end up targeting
loads of use-cases where confidentiality is absolutely
required.

- (In addition to the good points made by Geoffrey
Keating [2]) cleartext payloads would also assist in
device fingerprinting, making it easier to exploit
vulnerabilities at scale.

- IIUC there is also a desire to encrypt firmware
updates so that patches can be distributed more quickly
than attackers can reverse-engineer attacks. [4] I'm
not entirely sure if that's really likely to happen,
but if it were, then devices would need to be able to
use recommended ciphersuites in any case.

- TLS/AX.25 doesn't seem that good a plan in any
case - according to [3], which seems reasonable to
me, using clear-signed GPG is quicker and better
meets the oddball regulations. Attempting to deal
with those regulations by weakening TLS seems like
a very bad plan, as you'd fail in any case to achieve
interop with normal TLS applications like the web.
(And the advertising is as illegal as the crypto
apparently, though I do like that aspect:-)

- WRT unix sockets, I'm not clear that there's a
sufficiently important performance improvement in
real deployments to justify introducing weakened
ciphersuites - presumably mail servers are going to
use standard TLS libraries that (I hope!) won't be
offering NULL encryption, so I'd be surprised if
the right engineering decision was to prioritise
CPU to that extent, given the risks associated with
having weak ciphersuites present in widely used
implementations. IOW, it seems more sensible to me
for mail servers to just stick to using RECOMMENDED
ciphersuites. And given that you could use SASL
with Postfix/LMTP [5] I'm not sure why you'd want
a weirdo-version of TLS1.3 anyway but maybe there's
some reason I don't get.

- I think this WG has had to spend waaaay too much
time dealing with the "inspection of data" debate in
various forms, but we did get an answer (no consensus)
in the end for that. Niche use cases seem extremely
unlikely to me to justify revisiting that painful
topic.

So all in all, I just don't see a need for these
weak-by-design ciphersuites to even be defined. I'd
encourage folks who think they're needed to instead
think about how using RECOMMENDED ciphersuites might
make their implementations more widely applicable and
safer. Seems like a much more productive approach to
me anyway.

Regards,
S.

[1] https://tools.ietf.org/html/rfc7525
[2] https://mailarchive.ietf.org/arch/msg/tls/uI8xVgp7gTuJgwUyY-UgZfmUkRo
[3] https://tools.ietf.org/html/draft-ietf-suit-architecture-01#section-3.3
[4] https://www.tapr.org/pdf/DCC2010-AX.25-AuthenticationEffects-KE5LKY.pdf
[5] http://www.postfix.org/SASL_README.html#client_sasl

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 21 Aug 2018 12:10:17 +0000

"Vulnerable-by-design ciphersuites"? Vulnerable to what? 

Suck sites are designed to provide end-point authentication and traffic integrity. Care to explain/show how these properties would not hold?

Besides, it's been explained several times that some use cases do not require confidentiality, and in some use cases confidentiality is forbidden.

Regards,
Uri

Sent from my iPhone

> On Aug 21, 2018, at 07:42, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Aug 2018 09:12:09 -0400

> On Aug 21, 2018, at 12:32 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

I should note that disabling encryption is not always a performance
win.  Depending on the machine's hardware and assembly support in
libraries AEAD with AESGCM may be faster than SHA256 without encryption.

-- 
	Viktor.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 21 Aug 2018 09:15:21 -0400

Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 

I agree with Uri here, flexibility to cover these use cases to accommodate the actual security requirements may result in them using something instead of nothing.  It could be defined and not listed as Recommended as well.  This comes down to risk management and options, where the risk can be clearly explained and the lack of recommendation can also be explained.

Best regards,
Kathleen

---

From: Bill Frantz <[email-masked]>
Date: Tue, 21 Aug 2018 06:31:19 -0700

One area where there is a need for an integrity and 
authentication only suite is in amateur radio systems. In 
amateur radio, any encoding scheme which hides the meaning of a 
message is against the FCC regulations. However, remote control 
by radio could benefit from both integrity and authentication. 
The FCC regulations recognize this need and permit encryption of 
messages controlling amateur radio satellites.

Amateur radio digital protocols include some state of the art 
error detection and correction techniques, providing a kind of 
integrity, but they do not provide authentication. Amateurs have 
gotten by with a combination of very primitive authentication 
techniques and legal action after tracking attackers with radio 
direction finding.

While I'm not sure that this application area is important 
enough to be addressed by the TLS working group, if there are 
other application areas with similar needs, then perhaps these 
needs should be addressed.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray

---

From: "Andreas Walz" <[email-masked]>
Date: Tue, 21 Aug 2018 15:36:49 +0200

+1

I fully understand the pursuit of minimizing complexity in TLS. However,
banning from TLS all provisions to serve non-internet cases seems
suboptimal to me.

I think there is a whole universe of systems and applications that are
just at the very beginning of being armed with security features: think
of communication systems driving, e.g., industrial automation and
critical infrastructures. These are quite different from the internet
and the web (different threats, security requirements, architectures,
networks, resources, etc.). Still, IMHO it's not a niche at all; it's
just not as visible to most of us.

I strongly believe it is *not* a good idea to hold back all the valuable
experience condensed in TLS and entail the design of customized security
protocols for such systems. TLS is state-of-the-art and its benefits
should be accessible to as many systems as possible. 

Cheers,
Andi Walz 

>>> Kathleen Moriarty <[email-masked]> 08/21/18 3:20
PM >>>

> Suck sites are designed to provide end-point authentication and
traffic integrity. Care to explain/show how these properties would not
hold?
> 
> Besides, it's been explained several times that some use cases do not
require confidentiality, and in some use cases confidentiality is
forbidden.

I agree with Uri here, flexibility to cover these use cases to
accommodate the actual security requirements may result in them using
something instead of nothing.  It could be defined and not listed as
Recommended as well.  This comes down to risk management and options,
where the risk can be clearly explained and the lack of recommendation
can also be explained.

Best regards,
Kathleen 

>>> to document request for registrations of HMAC based cipher
selections
>> convince me that that>> me - to get interop for the few devices where AES being
>> [2]
https://mailarchive.ietf.org/arch/msg/tls/uI8xVgp7gTuJgwUyY-UgZfmUkRo
>> [3]
https://tools.ietf.org/html/draft-ietf-suit-architecture-01#section-3.3
>> [4]
https://www.tapr.org/pdf/DCC2010-AX.25-AuthenticationEffects-KE5LKY.pdf

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Aug 2018 10:06:20 -0400

> I wonder whether it's really helpful to call the result 'TLS' and

I'm agnostic w.r.t. confidentiality of application data -- we've
historically been bad at making decision about what does / does not need to
be confidential, but hey, it's your data.

However, the EE / NST arguments Geoff make here seem pretty compelling to
me.  They indicate to me that if a mechanism is defined where application
data is not encrypted, records that contain non-application data still need
to be encrypted.  That of course blows away the "code footprint" argument,
and it's not trivial to implement given how the application_data content
type has been overloaded in 1.3.

ISTM that in order to do this at all elegantly, you'd have to abandon using
application_data records for application data, since those have to be
encrypted for the above reasons), and instead either:

- Use a different record type (say plaintext_data)
- Use a different protocol that can be muxed with TLS (as with DTLS-SRTP)

Unfortunately the former approach would require a Standards Action.  So
maybe the latter is the way to go.

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Aug 2018 15:16:57 +0100

Hiya,

> "Vulnerable-by-design ciphersuites"? Vulnerable to what?

Accidental use, at least. If libraries implemented this
it could create a need for "!NULL" additions to random
configurations for example.

(I do accept that vulnerable-by-design might be considered
overstated, but I'm looking at his from a "part of TLS" POV
and not just at the lower level cryptographic mechanism.)

> traffic integrity. Care to explain/show how these properties would
> not hold?
>

I think I and others addressed those issues. Or tried to,
anyway;-) Assuming the only "forbidden" case means ham
radio. And it's I think fair to say that a number of times
when people have started out thinking they don't need
confidentiality, it turned out later that they did.

Cheers,
S.

> Regards, Uri
>>> On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote: All, A
>>> couple IoT consortiums are trying to embrace the improvements 
>>> would like to adopt the latest protocols, in this case TLS 1.3.
>>> To that extent, they have a strong need for mutual
>>> authentication, but integrity only (no confidentiality)
>>> requirements.
>>> 
>>> with TLS 1.3…..and are soliciting feedback from the WG on the
>>> draft and its path forward.
>> 
>> As ekr pointed out, with the new registration rules, there's
>> nothing to stop someone defining any old set of crypto stuff and
>> getting non-recommended codepoints.
>> 
>> That said, I don't consider that defining such vulnerable-by-design
>> ciphersuites is a good plan.
>> 
>> - It imposes costs on the non-niche users of TLS - once these
>> things are defined then developers and those who deploy/configure
>> applications using TLS need to check that they're not using these
>> undesirable ciphersuites, so costs are being displaced from niche
>> uses to the vast majority of implementations and deployments,
>> which seems to me to be a bad idea. And we know that people will
>> sometimes get those checks wrong leading to unexpected transmission
>> of plaintext over the Internet.
>> 
>> - Similarly, just defining such ciphersuites seems likely to lead
>> to less well tested and infrequently used code paths, which is
>> undesirable. (Assuming someone pays some developer to add these to
>> some library, which generally does seem to happen.)
>> 
>> - RFC7525 [1] is clear on this topic (after debate in the UTA WG) -
>> "Implementations MUST NOT negotiate the cipher suites with NULL
>> encryption" and I see nothing new to convince me that that ought
>> change for TLS1.3.
>> 
>> - Code footprint arguments aren't that convincing to me - to get
>> interop for the few devices where AES being present or absent could
>> make a real difference, you'd need an awful lot more profiling of
>> TLS or DTLS. I don't see evidence of that so the interop/footprint
>> arguments seem pretty weak. I'd also bet that any useful "tiny 
>> footprint" profile of that kind would end up targeting loads of
>> use-cases where confidentiality is absolutely required.
>> 
>> - (In addition to the good points made by Geoffrey Keating [2])
>> cleartext payloads would also assist in device fingerprinting,
>> making it easier to exploit vulnerabilities at scale.
>> 
>> - IIUC there is also a desire to encrypt firmware updates so that
>> patches can be distributed more quickly than attackers can
>> reverse-engineer attacks. [4] I'm not entirely sure if that's
>> really likely to happen, but if it were, then devices would need to
>> be able to use recommended ciphersuites in any case.
>> 
>> - TLS/AX.25 doesn't seem that good a plan in any case - according
>> to [3], which seems reasonable to me, using clear-signed GPG is
>> quicker and better meets the oddball regulations. Attempting to
>> deal with those regulations by weakening TLS seems like a very bad
>> plan, as you'd fail in any case to achieve interop with normal TLS
>> applications like the web. (And the advertising is as illegal as
>> the crypto apparently, though I do like that aspect:-)
>> 
>> - WRT unix sockets, I'm not clear that there's a sufficiently
>> important performance improvement in real deployments to justify
>> introducing weakened ciphersuites - presumably mail servers are
>> going to use standard TLS libraries that (I hope!) won't be 
>> offering NULL encryption, so I'd be surprised if the right
>> engineering decision was to prioritise CPU to that extent, given
>> the risks associated with having weak ciphersuites present in
>> widely used implementations. IOW, it seems more sensible to me for
>> mail servers to just stick to using RECOMMENDED ciphersuites. And
>> given that you could use SASL with Postfix/LMTP [5] I'm not sure
>> why you'd want a weirdo-version of TLS1.3 anyway but maybe there's 
>> some reason I don't get.
>> 
>> - I think this WG has had to spend waaaay too much time dealing
>> with the "inspection of data" debate in various forms, but we did
>> get an answer (no consensus) in the end for that. Niche use cases
>> seem extremely unlikely to me to justify revisiting that painful 
>> topic.
>> 
>> So all in all, I just don't see a need for these weak-by-design
>> ciphersuites to even be defined. I'd encourage folks who think
>> they're needed to instead think about how using RECOMMENDED
>> ciphersuites might make their implementations more widely
>> applicable and safer. Seems like a much more productive approach
>> to me anyway.
>> 
>> Regards, S.
>> 
>> [1] https://tools.ietf.org/html/rfc7525 [2]
>> 
>> 
>> <0x5AB2FAF17B172BEA.asc> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 21 Aug 2018 10:24:12 -0400

On Aug 21, 2018, at 10:16, Stephen Farrell <[email-masked]> wrote:
—
Regards,
Uri Blumenthal                              Voice: (781) 981-1638
Secure Resilient Systems  and Technologies  Fax:   (781) 981-7537
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA  02421-9185

Web:  http://www.ll.mit.edu/mission/cybersec/cybersec-bios/blumenthal-bio.html

> and not just at the lower level cryptographic mechanism.)

I disagree, but I see your point.

> anyway;-)

“Tried” is the right term in this context. ;-)

> Assuming the only "forbidden" case means ham
> radio.

Incorrect. But probably the most respectable case. ;-)

> And it's I think fair to say that a number of times

I strongly disagree here.

It’s been shown that confidentiality without integrity tends to get broken. It has never been shown that integrity without confidentiality has any issues.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Aug 2018 15:24:44 +0100

> should be accessible to as many systems as possible. 

I agree. Quoting the meat of the abstract of RFC8446:

   TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

Using TLS in non-Internet contexts is just fine. Possibly
weakening the "prevent eavesdropping" part is the issue here.
Confidentiality is required for lots of reasons, e.g. bearer
token security, or maybe even firmware updates, as pointed
out earlier in this thread.

Cheers,
S.

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 14:27:25 +0000

(I’m responding  a few different points made here)

In general, although this seems like a niche application, there are actually millions of Industrial Ethernet nodes, with the numbers trending upward.  As mentioned, many of these are relying on older protocols designed without security in mind.  Our industry has had a debate around using TLS vs. creating something specific.  Many of us prefer to rely on the security benefits of TLS.  To another point, although I work for Rockwell Automation, here I am working in my capacity within ODVA, a standards group for Industrial Communications that has several large vendors as members.  We have adopted TLS to protect our industrial Ethernet traffic, and one of the selling points of TLS 1.2 was the ability to use NULL encryption.

NULL encryption is not really as much about code size but capability of the devices.  The TLS handshake of course contains some “heavyweight” operations, although handshakes are pretty infrequent as these connections are often quite long-lived.  Once the handshake is over, the I/O data that is transferred is often quite sensitive to latency, and although the encryption overhead might not seem like much when the HMAC is considered, it is still a case where in many applications every bit counts.  Regarding older hardware that exists for many years, some hardware does have cryptographic acceleration although may not have AES-GCM, rather SHA-256 HMAC.  Alternatively, the hardware might not have any crypto acceleration as it was designed without TLS in mind.  At the same time we’d like to secure this traffic via a firmware upgrade.  Despite this, if using encryption drops performance enough users will simply not use it, which is a net worse outcome.  Users will likely not upgrade hardware for many years due to a variety of industry factors.

Kathleen’s comment about defining NULL encryption but being clear about the risks resonates with me.  I’m certainly not suggesting that NULL encryption is needed in all cases, but there are times (as discussed here and in the RFC draft) where it could be quite beneficial.

Thanks and Best Regards,

--Jack

From: TLS [mailto:[email-masked]] On Behalf Of Andreas Walz
Sent: Tuesday, August 21, 2018 9:37 AM
To: [email-masked]
Cc: ncamwing=[email-masked]
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites

+1

I fully understand the pursuit of minimizing complexity in TLS. However, banning from TLS all provisions to serve non-internet cases seems suboptimal to me.

I think there is a whole universe of systems and applications that are just at the very beginning of being armed with security features: think of communication systems driving, e.g., industrial automation and critical infrastructures. These are quite different from the internet and the web (different threats, security requirements, architectures, networks, resources, etc.). Still, IMHO it's not a niche at all; it's just not as visible to most of us.

I strongly believe it is *not* a good idea to hold back all the valuable experience condensed in TLS and entail the design of customized security protocols for such systems. TLS is state-of-the-art and its benefits should be accessible to as many systems as possible.

Cheers,
Andi Walz

>>> Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> 08/21/18 3:20 PM >>>

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]<mailto:[email-masked]>> wrote:
>

Best regards,
Kathleen

>
> Regards,
> Uri
>
> Sent from my iPhone
>
>> On Aug 21, 2018, at 07:42, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 10:58:10 -0400

Thanks, Jack, but could you respond to the specific questions that we asked
you?   Earlier you were saying that your motivation for using NULL ciphers
was that you had specific hardware that couldn't implement encryption due
to lack of horsepower or memory.   Now you seem to be saying something
completely different.   It's going to be difficult for us to understand
your requirements if you talk about different things in each message.

On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky <[email-masked]>
wrote:

> In general, although this seems like a niche application, there are
> actually millions of Industrial Ethernet nodes, with the numbers trending
> upward.  As mentioned, many of these are relying on older protocols
> designed without security in mind.  Our industry has had a debate around
> using TLS vs. creating something specific.  Many of us prefer to rely on
> the security benefits of TLS.  To another point, although I work for
> Rockwell Automation, here I am working in my capacity within ODVA, a
> standards group for Industrial Communications that has several large
> vendors as members.  We have adopted TLS to protect our industrial Ethernet
> traffic, and one of the selling points of TLS 1.2 was the ability to use
> NULL encryption.
>
>
>
> NULL encryption is not really as much about code size but capability of
> the devices.  The TLS handshake of course contains some “heavyweight”
> operations, although handshakes are pretty infrequent as these connections
> are often quite long-lived.  Once the handshake is over, the I/O data that
> is transferred is often quite sensitive to latency, and although the
> encryption overhead might not seem like much when the HMAC is considered,
> it is still a case where in many applications every bit counts.  Regarding
> older hardware that exists for many years, some hardware does have
> cryptographic acceleration although may not have AES-GCM, rather SHA-256
> HMAC.  Alternatively, the hardware might not have any crypto acceleration
> as it was designed without TLS in mind.  At the same time we’d like to
> secure this traffic via a firmware upgrade.  Despite this, if using
> encryption drops performance enough users will simply not use it, which is
> a net worse outcome.  Users will likely not upgrade hardware for many years
> due to a variety of industry factors.
>
>
>
> Kathleen’s comment about defining NULL encryption but being clear about
> the risks resonates with me.  I’m certainly not suggesting that NULL
> encryption is needed in all cases, but there are times (as discussed here
> and in the RFC draft) where it could be quite beneficial.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Andreas Walz
> *Sent:* Tuesday, August 21, 2018 9:37 AM
> *To:* [email-masked]
> *Cc:* ncamwing=[email-masked]
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> just at the very beginning of being armed with security features: think of
> communication systems driving, e.g., industrial automation and critical
> infrastructures. These are quite different from the internet and the web
> (different threats, security requirements, architectures, networks,
> resources, etc.). Still, IMHO it's not a niche at all; it's just not as
> visible to most of us.
>
> protocols for such systems. TLS is state-of-the-art and its benefits should
> be accessible to as many systems as possible.
>
>
>
> Cheers,
> Andi Walz
>
>
>
>
> >>> Kathleen Moriarty <[email-masked]> 08/21/18 3:20 PM
> >>>
>
>
> > Suck sites are designed to provide end-point authentication and traffic
> integrity. Care to explain/show how these properties would not hold?
> >
> require confidentiality, and in some use cases confidentiality is forbidden.
>
> I agree with Uri here, flexibility to cover these use cases to accommodate
> the actual security requirements may result in them using something instead
> of nothing. It could be defined and not listed as Recommended as well. This
> comes down to risk management and options, where the risk can be clearly
> explained and the lack of recommendation can also be explained.
>
> Best regards,
> Kathleen
>
> >
> > Regards,
> > Uri
> >
> > Sent from my iPhone
> >

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 15:20:17 +0000

Hi Ted,

My apologies for being opaque.  There are many different device/applications/installations so I am sorry if I am mixing ideas here.  Generally the NULL ciphers have the benefit around allowing higher performance for devices that are lower horsepower.  Code space can certainly be a concern, but I think for industrial applications it’s more around throughput of high speed I/O, combined with the use cases that derive little benefit from the confidentiality of this data.  “Horsepower” is of course a vague term in of itself, so here I’m talking about things that would impact packet processing; this includes processor speed, available high speed RAM, presence of/lack of crypto acceleration (not in many Industrial Ethernet devices but growing).  I wouldn’t put the executable code size as high on the list of concerns as these items, although there are certainly devices that are limited in this.  This horsepower limitation is directly related to the fact that these devices are expected to function for many years.

I’m happy to clarify any of these points further if needed.

Thanks and Best Regards,

--Jack

From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, August 21, 2018 10:58 AM
To: Jack Visoky <[email-masked]>
Cc: Andreas Walz <[email-masked]>; [email-masked]; ncamwing=[email-masked]
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Thanks, Jack, but could you respond to the specific questions that we asked you?   Earlier you were saying that your motivation for using NULL ciphers was that you had specific hardware that couldn't implement encryption due to lack of horsepower or memory.   Now you seem to be saying something completely different.   It's going to be difficult for us to understand your requirements if you talk about different things in each message.

On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:
(I’m responding  a few different points made here)

Thanks and Best Regards,

--Jack

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andreas Walz
Sent: Tuesday, August 21, 2018 9:37 AM
To: [email-masked]<mailto:[email-masked]>
Cc: ncamwing=[email-masked]<mailto:[email-masked]>
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites

+1

Cheers,
Andi Walz

Best regards,
Kathleen

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 21 Aug 2018 15:44:38 +0000

Hi,

Just to add on this, there are different standards in power system automation, which utilize and profile TLS to avoid defining an own security protocol and rely on existing security protocols. This is done for instance in IEC 62351, which requires mutual authentication based on certificates and allows integrity only cipher suites. Within a utility network it may be necessary to monitor the information that is used for control and/or measurement of switchgear or similar entities. Confidentiality it not the first priority here and if the communication crosses the internet (from a substation to a control center), additional measures are used. The same requirement for passive monitoring exists in railway systems for interlocking communication. The intention here is also to be able to monitor the signaling without the need to terminate a security protocol.

If there would be support for integrity ciphers in TLS 1.3 it would enable the straight forward switch from TLS 1.2 also in these environments by keeping existing monitoring options.

Best regards
Steffen Fries

From: TLS <[email-masked]> On Behalf Of Andreas Walz
Sent: Dienstag, 21. August 2018 15:37
To: [email-masked]
Cc: ncamwing=[email-masked]
Subject: Re: [TLS] integrity only ciphersuites

+1

Cheers,
Andi Walz

Best regards,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Aug 2018 15:52:38 +0000

*   If there would be support for integrity ciphers in TLS 1.3 it would enable the straight forward switch from TLS 1.2 also in these environments by keeping existing monitoring options.

Why do you want to move to TLS 1.3?  Why isn’t your existing solution good enough?

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 21 Aug 2018 16:00:42 +0000

Ø  If there would be support for integrity ciphers in TLS 1.3 it would enable the straight forward switch from TLS 1.2 also in these environments by keeping existing monitoring options.

Why do you want to move to TLS 1.3?  Why isn’t your existing solution good enough?
[stf] Currently it is sufficient to use TLS 1.2- For certain use cases the utilized components have a rather long lifetime. One assumption is that TLS 1.3 will exist longer that TLS 1.2 and that certain software tools (also browsers) may not support TLS 1.2 in the future (I know there is currently not intention for a deprecation of 1.2, but if a component is in the field for 20 years, it may become more likely). Having the option to also support TLS 1.3 on such devices now, may ensure that there are accessible by standard software also in the more distant future.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 12:12:29 -0400

This is a situation where there is a clear alternative: use IPsec.   IPsec
is ideal for the problem space you are in.   TLS is actually really not
ideal.   You are trying to cram a round peg into a square hole.

On Tue, Aug 21, 2018 at 12:00 PM, Fries, Steffen <[email-masked]>
wrote:

>
>
>
>
> Ø  If there would be support for integrity ciphers in TLS 1.3 it would
> enable the straight forward switch from TLS 1.2 also in these environments
> by keeping existing monitoring options.
>
>
>
> [stf] Currently it is sufficient to use TLS 1.2- For certain use cases the
> utilized components have a rather long lifetime. One assumption is that TLS
> 1.3 will exist longer that TLS 1.2 and that certain software tools (also
> browsers) may not support TLS 1.2 in the future (I know there is currently
> not intention for a deprecation of 1.2, but if a component is in the field
> for 20 years, it may become more likely). Having the option to also support
> TLS 1.3 on such devices now, may ensure that there are accessible by
> standard software also in the more distant future.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Aug 2018 16:13:35 +0000

*   [stf] Currently it is sufficient to use TLS 1.2- For certain use cases the utilized components have a rather long lifetime. One assumption is that TLS 1.3 will exist longer that TLS 1.2 and that certain software tools (also browsers) may not support TLS 1.2 in the future  …

Most browsers already do not support NULL encryption, and it is highly unlikely that any will add it for 1.3.  Have you any indication otherwise?  If you’re not going to use the algorithms in general use on the public Internet, then you should expect that standard clients such as browsers, will not work.  PeterG can attest to this. :)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 12:15:36 -0400

I asked you if you have any specific devices for which this is an issue.
 Do you?   How did you determine that it was an issue?   Do you have A/B
testing results on power consumption and/or performance of a null cipher
suite versus encryption?

On Tue, Aug 21, 2018 at 11:20 AM, Jack Visoky <[email-masked]>
wrote:

> Hi Ted,
>
>
>
> My apologies for being opaque.  There are many different
> device/applications/installations so I am sorry if I am mixing ideas
> here.  Generally the NULL ciphers have the benefit around allowing higher
> performance for devices that are lower horsepower.  Code space can
> certainly be a concern, but I think for industrial applications it’s more
> around throughput of high speed I/O, combined with the use cases that
> derive little benefit from the confidentiality of this data.  “Horsepower”
> is of course a vague term in of itself, so here I’m talking about things
> that would impact packet processing; this includes processor speed,
> available high speed RAM, presence of/lack of crypto acceleration (not in
> many Industrial Ethernet devices but growing).  I wouldn’t put the
> executable code size as high on the list of concerns as these items,
> although there are certainly devices that are limited in this.  This
> horsepower limitation is directly related to the fact that these devices
> are expected to function for many years.
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Tuesday, August 21, 2018 10:58 AM
> *To:* Jack Visoky <[email-masked]>
> *Cc:* Andreas Walz <[email-masked]>; [email-masked]; ncamwing=
> [email-masked]
> *Subject:* Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
>
>
>
> Thanks, Jack, but could you respond to the specific questions that we
> asked you?   Earlier you were saying that your motivation for using NULL
> ciphers was that you had specific hardware that couldn't implement
> encryption due to lack of horsepower or memory.   Now you seem to be saying
> something completely different.   It's going to be difficult for us to
> understand your requirements if you talk about different things in each
> message.
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Aug 2018 17:37:30 +0100

> testing results on power consumption and/or performance of a null cipher

If doing such comparisons, then it's very well worth noting the
significant differences between e.g. h/w accelerated AES, vs s/w
AES vs chacha. It'd be hard to evaluate claims about difficulty
of implementation/deployment without that.

S.

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 21 Aug 2018 16:53:43 +0000

On 21. Aug 2018, at 18:13, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

True. I was more referring to an embedded device, which currently supports TLS 1.2 (for using integrity only) for machine to machine communication  If this device is accessed by a service technician, it will also use today cipher suites with encryption. If a browser provider decides to deprecate TLS 1.2 in the future, access by standard software would be hindered. This would end up in a device supporting TLS 1.3 for service technicians access and 1.2 for machine to machine communication to (still) have integrity only.

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 17:02:25 +0000

We (as well as other vendors) have certainly done testing on this.  We have some products with hardware accelerators and some without, testing has been performed across a wide range.  AES is always an adder when done in software, and in many hardware installations it is still a timing adder (and always a power consumption adder).  Less testing was done with Cha Cha as that was not as prominent in TLS 1.2.

The fact is that for ours and many other vendors devices the encryption is a non-trivial adder for a number of I/O applications.

Thanks and Best Regards,

--Jack

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2018 12:38 PM
To: Ted Lemon <[email-masked]>; Jack Visoky <[email-masked]>
Cc: ncamwing=[email-masked]; [email-masked]
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

On 21/08/18 17:15, Ted Lemon wrote:
> testing results on power consumption and/or performance of a null 
> cipher suite versus encryption?

If doing such comparisons, then it's very well worth noting the significant differences between e.g. h/w accelerated AES, vs s/w AES vs chacha. It'd be hard to evaluate claims about difficulty of implementation/deployment without that.

S.

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 17:06:40 +0000

Just to pile on what Steffen is saying, the motivation for this is mainly around device communication that happens at high speeds (sub millisecond is not uncommon for an update rate).  The communications is generally not HTTP, but rather industrial protocols built on TCP and UDP.

Thanks and Best Regards,

--Jack

From: TLS [mailto:[email-masked]] On Behalf Of Fries, Steffen
Sent: Tuesday, August 21, 2018 12:54 PM
To: Salz, Rich <[email-masked]>
Cc: ncamwing=[email-masked]; [email-masked]
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites

On 21. Aug 2018, at 18:13, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
?  If there would be support for integrity ciphers in TLS 1.3 it would enable the straight forward switch from TLS 1.2 also in these environments by keeping existing monitoring options.

Why do you want to move to TLS 1.3?  Why isn't your existing solution good enough?

?  [stf] Currently it is sufficient to use TLS 1.2- For certain use cases the utilized components have a rather long lifetime. One assumption is that TLS 1.3 will exist longer that TLS 1.2 and that certain software tools (also browsers) may not support TLS 1.2 in the future  ...

Most browsers already do not support NULL encryption, and it is highly unlikely that any will add it for 1.3.  Have you any indication otherwise?  If you're not going to use the algorithms in general use on the public Internet, then you should expect that standard clients such as browsers, will not work.  PeterG can attest to this. :)

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Aug 2018 17:12:13 +0000

Now I think I am as confused as Stephen and others.

One justification was “small footprint.”  But now you’re saying that for debugging encryption (standard?) ciphers are used for browser access?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 13:29:05 -0400

So rather than upgrading to TLS 1.3, why not just upgrade to IPsec?
 You're going to have to change what you do anyway—rather than arguing with
us why not bypass us entirely?

On Tue, Aug 21, 2018 at 1:06 PM, Jack Visoky <[email-masked]>
wrote:

> Just to pile on what Steffen is saying, the motivation for this is mainly
> around device communication that happens at high speeds (sub millisecond is
> not uncommon for an update rate).  The communications is generally not
> HTTP, but rather industrial protocols built on TCP and UDP.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Fries, Steffen
> *Sent:* Tuesday, August 21, 2018 12:54 PM
> *To:* Salz, Rich <[email-masked]>
> *Cc:* ncamwing=[email-masked]; [email-masked]
> On 21. Aug 2018, at 18:13, Salz, Rich <[email-masked]> wrote:
>
> ?  If there would be support for integrity ciphers in TLS 1.3 it would
> ?  [stf] Currently it is sufficient to use TLS 1.2- For certain use cases
> the utilized components have a rather long lifetime. One assumption is that
> TLS 1.3 will exist longer that TLS 1.2 and that certain software tools
> (also browsers) may not support TLS 1.2 in the future  …
>
>
>
> Most browsers already do not support NULL encryption, and it is highly
> unlikely that any will add it for 1.3.  Have you any indication otherwise?
> If you’re not going to use the algorithms in general use on the public
> Internet, then you should expect that standard clients such as browsers,
> will not work.  PeterG can attest to this. :)
>
>
>
> True. I was more referring to an embedded device, which currently supports
> TLS 1.2 (for using integrity only) for machine to machine communication  If
> this device is accessed by a service technician, it will also use today
> cipher suites with encryption. If a browser provider decides to deprecate
> TLS 1.2 in the future, access by standard software would be hindered. This
> would end up in a device supporting TLS 1.3 for service technicians access
> and 1.2 for machine to machine communication to (still) have integrity
> only.
>

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 17:34:24 +0000

Hi Rich,

I’m not sure if I’m following the question, but what was meant was that these ciphers are generally NOT used for browser access.  Machine to machine communication usually does not involve a browser.  Apologies if I’ve misunderstood the question.

Thanks and Best Regards,

--Jack

From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Tuesday, August 21, 2018 1:12 PM
To: Fries, Steffen <[email-masked]>
Cc: ncamwing=[email-masked]; [email-masked]
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 13:39:07 -0400

If the device implements the cipher so as to talk to the browser, it's
clearly capable of implementing the cipher...

On Tue, Aug 21, 2018 at 1:34 PM, Jack Visoky <[email-masked]>
wrote:

> Hi Rich,
>
>
>
> I’m not sure if I’m following the question, but what was meant was that
> these ciphers are generally NOT used for browser access.  Machine to
> machine communication usually does not involve a browser.  Apologies if
> I’ve misunderstood the question.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Salz, Rich
> *Sent:* Tuesday, August 21, 2018 1:12 PM
> *To:* Fries, Steffen <[email-masked]>
> One justification was “small footprint.”  But now you’re saying that for
> debugging encryption (standard?) ciphers are used for browser access?
>
>
>

---

From: Bill Frantz <[email-masked]>
Date: Tue, 21 Aug 2018 10:40:07 -0700

On 8/21/18 at 7:24 AM, [email-masked] (Stephen 

>tampering, and message forgery.

I spent some time thinking about integrity protected, 
authenticated, replay resistant protocols during the late 1990s 
as the crypto wars were running hot and heavy. I decided the 
problem wasn't as simple as the fully encrypted protocols of 
which TLS is an example.

A number of people have concerns about building connections with 
no secrecy, even when secrecy is desired by the endpoints, 
either because of specification errors or because of downgrade 
attacks. I share those concerns, and would be willing to 
consider a protocol that uses entirely different packet 
identifiers from those used by TLS as a way to reduce this problem.

I do think that the TLS working group is well qualified to 
analyse the design of such a protocol.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Since the IBM Selectric, keyboards have gotten
408-356-8506       | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Aug 2018 17:45:41 +0000

*   I’m not sure if I’m following the question, but what was meant was that these ciphers are generally NOT used for browser access.  Machine to machine communication usually does not involve a browser.  Apologies if I’ve misunderstood the question.

You understood me.  So the devices (or rather at least some of them since they are splendiferous in their variances) do speak common TLS.  But not for M2M.  That part confuses me, since “too small to encrypt” was a reason given.

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 17:53:17 +0000

Hi Ted,

A few points:

1.       Don’t assume there is any browser involved.  There is often no browser.

2.       Even if there is a browser (and see point 1 before assuming) any HTTP communication would be at a much much slower rate than machine to machine I/O

Hope that clears it up.

Thanks and Best Regards,

--Jack

From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, August 21, 2018 1:39 PM
To: Jack Visoky <[email-masked]>
Cc: Salz, Rich <rsalz=[email-masked]>; Fries, Steffen <[email-masked]>; ncamwing=[email-masked]; [email-masked]
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

If the device implements the cipher so as to talk to the browser, it's clearly capable of implementing the cipher...

On Tue, Aug 21, 2018 at 1:34 PM, Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rich,

Thanks and Best Regards,

--Jack

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Salz, Rich
Sent: Tuesday, August 21, 2018 1:12 PM
To: Fries, Steffen <[email-masked]<mailto:[email-masked]>>
Cc: ncamwing=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 13:56:28 -0400

What kind of bandwidth are we talking about here?   Also, could you answer
my question about IPsec?

On Tue, Aug 21, 2018 at 1:53 PM, Jack Visoky <[email-masked]>
wrote:

> 2.       Even if there is a browser (and see point 1 before assuming) any
> HTTP communication would be at a much much slower rate than machine to
> machine I/O
>
>
>
> Hope that clears it up.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *Sent:* Tuesday, August 21, 2018 1:39 PM
> *Cc:* Salz, Rich <rsalz=[email-masked]>; Fries, Steffen <
> [email-masked]>; ncamwing=[email-masked];
> [email-masked]

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 17:58:42 +0000

Hi Rich,

M2M might be common TLS, but with something else at the application layer.  I’ll give this example, but admittedly the terminology is confusing: there is another protocol that is called EtherNet/IP (here IP stands for Industrial Protocol, hence the concern about confusion). In this case this protocol is built upon TCP and UDP, but then above that there is a different protocol meant for machine to machine communication that will enable a number of industrial applications.  What we did in ODVA was to add TLS (and DTLS in some cases) to protect this communication.  This communication is often high speed and latency is a major concern.  So it is standard TLS, but rather than HTTP on top of the TLS, it is an Industrial Protocol.  Even if the device is “capable” of encryption, encrypting the data adds overhead and is unnecessary in some applications.  So capable might mean it can do encryption, but not at the speeds necessary for machine to machine I/O.

Thanks and Best Regards,

--Jack

From: Salz, Rich [mailto:[email-masked]]
Sent: Tuesday, August 21, 2018 1:46 PM
To: Jack Visoky <[email-masked]>; Salz, Rich <rsalz=[email-masked]>; Fries, Steffen <[email-masked]>
Cc: ncamwing=[email-masked]; [email-masked]
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Ø  I’m not sure if I’m following the question, but what was meant was that these ciphers are generally NOT used for browser access.  Machine to machine communication usually does not involve a browser.  Apologies if I’ve misunderstood the question.

---

From: Jack Visoky <[email-masked]>
Date: Tue, 21 Aug 2018 18:08:25 +0000

Could you please clarify on what you mean by bandwidth?  Are you talking about if a device has a 100 Mb connection or 10 Mb connection, or something else?  Also, processor speed and device capability is often a limiting factor so I’m not sure how relevant bandwidth is, but I might just not be following your train of thought.

IPsec was something that was looked at it detail, and tried in some installations.  It certainly has a place but we’ve found it’s not as generally applicable as TLS.  Reasons have to do with the complexity of configuration as well as difficulty setting up the network.  Another way to put this is that the market was not receptive to IPsec as a general solution.

In general we have a lot of respect for what was done with TLS and it’s wide adoption.  We’ve adopted it in a number of protocols under TLS 1.2 and would like to do the same with TLS 1.3.

Thanks and Best Regards,

--Jack

Sent: Tuesday, August 21, 2018 1:56 PM

What kind of bandwidth are we talking about here?   Also, could you answer my question about IPsec?

On Tue, Aug 21, 2018 at 1:53 PM, Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted,

A few points:

Hope that clears it up.

Thanks and Best Regards,

--Jack

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 21, 2018 1:39 PM
To: Jack Visoky <[email-masked]<mailto:[email-masked]>>
Cc: Salz, Rich <rsalz=[email-masked]<mailto:[email-masked]>>; Fries, Steffen <[email-masked]<mailto:[email-masked]>>; ncamwing=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Thanks and Best Regards,

--Jack

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Aug 2018 14:11:46 -0400

> On Aug 21, 2018, at 1:29 PM, Ted Lemon <[email-masked]> wrote:
> 
>   You're going to have to change what you do anyway—rather than arguing with us why not bypass us entirely?

TLS is not just a WWW protocol.  Other transport security use-cases
should not have to justify their existence.

It is, of course, appropriate to make sure that proposed TLS code-points
that cater to specialized needs are well thought out and include
suitable security considerations.

It is also reasonable to check that the requirements are not already
met without the proposed code-points.

I am concerned that we are going beyond that to questioning the
legitimacy of the use-cases.  IPsec is rarely a practical alternative
to TLS.

That said, TLS-LTS (a TLS 1.2 profile) may well be a good long-term
choice where TLS 1.3 is not sufficiently compatible.

As for TLS 1.3, it is indeed missing both null encryption and null
authentication ciphers.  I've not seen any evidence that their
presence in TLS 1.2 has led to either widespread support or
non-negligible accidental misuse.

TLS in SMTP is (still) largely unauthenticated opportunistic TLS,
and in almost all cases certificate verification errors get ignored
by sending MTAs.  When doing opportunistic unauthenticated TLS,
Postfix goes a step further and prefers ADH/AECDH cipher-suites (with
TLS <= 1.2), since any presented certificates will be ignored.
The null auth ciphers are automatically disabled when authentication
is required.

Similarly, Postfix provides either NO null encryption cipher-suites,
or ONLY null encryption cipher-suites.  One is unlikely to stumble
into a null-only configuration by accident and not notice.

With appropriate documentation, sensible default settings, and
configuration interfaces that make good choices easy and bad
choices more difficult, one can safely provide support for
non-mainstream use-cases.

This is not to say that null encryption ciphers for TLS 1.3 are
unconditionally good, their specification would need to provide
sound security considerations and be fit for purpose.  But I do
think that we should not reject the proposal out of hand.

-- 
-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Aug 2018 11:18:47 -0700

On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni <[email-masked]>
wrote:

> authentication ciphers.

If by "null authentication" you mean "without certificates", then TLS 1.3
does
support these via RFC 7250. See:

https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.5

> think that we should not reject the proposal out of hand.

This isn't a matter of rejecting or accepting them. As I said at the
beginning of
this thread. No TLS WG approval is required to get a code point.

The relevant questions are:

1. Should they be marked "Recommended" in the registry?
2. Should the TLS WG spend time reviewing these documents?

Can the authors of this draft please say what they are looking for here?

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Aug 2018 14:33:53 -0400

> On Aug 21, 2018, at 2:18 PM, Eric Rescorla <[email-masked]> wrote:
> 
> If by "null authentication" you mean "without certificates", then TLS 1.3 does

My comment was about ADH/AECDH cipher-suites, in which the server
does not sign the key exchange, because it has no keys and the
client has no intention/means to authenticate such a signature.

You are of course right that TLS 1.3 supports raw public keys,
which make it possible to do away with X.509 support.  I would
not call these null authentication, since DANE or key pinning
(much less scalably) make it possible to authenticate raw public
keys.

I've not yet seen raw public key support in any mainstream
TLS libraries, though admittedly my focus is primarily on
OpenSSL.  Do any of NSS, GnuTLS, BoringSSL, LibreSSL, ...
support raw public keys?

In the case of OpenSSL, adding such support is difficult, because
the assumption that the peer returns X.509 certificates and not
some more general data type is baked into the API.  We'd need to
invent some sort of special X.509 object that holds only a public
key, but behaves in some sensible way when used with functions
that expect X.509 certificates.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Aug 2018 11:39:27 -0700

> client has no intention/means to authenticate such a signature.

Yes. TLS 1.3 explicitly does not support those.

> that expect X.509 certificates.

Or you could just generate a fresh signing key for each connection.

-Ekr

---

From: David Benjamin <[email-masked]>
Date: Tue, 21 Aug 2018 13:44:55 -0500

> that expect X.509 certificates.

Add a separate function? It's reasonable for a caller which configures a
client to expect raw public keys to call a function that returns the peer
identity as a raw public key. Likewise, it's reasonable for a caller
configuring a server which uses raw public keys to call a
raw-public-key-specific configuration function. The same goes for any other
non-certificate-based authentication.

We have no plans to support this feature in BoringSSL, but if a need of
this shape ever arised, that's how I would imagine doing it.

David

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 21 Aug 2018 18:45:19 +0000

No they should not be recommended (as a typical TLS use case includes confidentiality requirement).

Yes this WG should review them and make a security statement, e.g., like "we reviewed these suites and found that they do provide authentication and integrity protection. No other protection such as confidentiality is provided" (as should be obvious from their names).

I suspect the authors are looking for code point assignment and general approval here, but they can speak for themselves. ;-)

Regards,
Uri

Sent from my iPhone

> On Aug 21, 2018, at 14:20, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni <[email-masked]> wrote:
>> 
>> 
> This isn't a matter of rejecting or accepting them. As I said at the beginning of

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Aug 2018 09:49:13 +1000

On Wed, Aug 22, 2018 at 12:07 AM Richard Barnes <[email-masked]> wrote:
> I'm agnostic w.r.t. confidentiality of application data -- we've historically been bad at making decision about what does / does not need to be confidential, but hey, it's your data.

Isn't this assumption - "this data is mine" - part of the reason we
get into trouble here?  That is, the decision is often based on a
mistaken assumption about who might be affected by a loss of
confidentiality.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 22 Aug 2018 01:55:47 +0000

Viktor Dukhovni <[email-masked]> writes:

>I've not yet seen raw public key support in any mainstream TLS libraries,
>though admittedly my focus is primarily on OpenSSL.  Do any of NSS, GnuTLS,
>BoringSSL, LibreSSL, ... support raw public keys?

I've never seen it either.  My code does actually support them, but not in the
way you think, for devices that don't have the ability to deal with certs
there's the memcpy()-into-send() certificate implementation I've mentioned
before, you memcpy() a pre-encoded cert chain onto the network, and for
receiving memcpy() the data in and pick out the SPKI.  So in effect it's raw
public keys, but to anyone watching it looks like it's certificates.  There
are other embedded implementations that do this too, it's a pretty obvious
optimisation (in other words I'm not trying to claim credit for inventing it).

>We'd need to invent some sort of special X.509 object that holds only a
>public key, but behaves in some sensible way when used with functions that
>expect X.509 certificates.

That's exactly what my code does, but with certificates
(CONFIG_USE_PSEUDOCERTIFICATES).  So there's no need for raw public keys, you
just treat certs as raw keys and everything works the way it already does with
certificates.

Is there any known actual use of raw public keys for TLS?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 22 Aug 2018 02:15:58 +0000

Salz, Rich <rsalz=[email-masked]> writes:

>Internet, then you should expect that standard clients such as browsers, will
>not work. PeterG can attest to this. :)

I'm going to have to handwave a bit on this, but a lot of TLS in embedded is
purely M2M, e.g. in IEDs (that's "intelligent electronic device", not
something that goes bang, although sometimes the things they control like
reclosers can go bang).  One or two levels above that are supervisory systems
that may need to talk a non-SCADA-profile TLS, but then they're often running
Windows or something similar and will talk whatever the browser needs.  So in
effect you've got a translation layer from SCADA-profile-TLS to whatever form
of TLS is in fashion in browsers at the moment.

Alternatively, you get extremely expensive control center software that
probably just wraps the Windows WebBrowser control in a custom app, although
I've seen some that use oddball ancient cipher suites so presumably they're
using the programmability of the components to ensure continued support for
older deployed gear.

That's only a high-level, handwavy view...

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 22 Aug 2018 02:51:57 +0000

Jack Visoky <[email-masked]> writes:

>What we did in ODVA was to add TLS (and DTLS in some cases) to protect this
>communication.

What about using LoRa security?  That's actually a really nice design for a
lot of SCADA environments (particularly for something that came from a behind-
closed-doors background), and not tied to LoRaWAN in any way.  In particular
they took a complete-infrastructure view, not just "we'll specify the crypto,
the rest is someone else's problem", e.g. the concept of device <-> gateway
and device <-> application security, OTA enrolment, etc.  If you're doing M2M
then you don't need TLS, just use LoRa.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Aug 2018 23:08:46 -0400

> optimisation (in other words I'm not trying to claim credit for inventing it).

Some DANE users have reached similar conclusions, though a bit of
ASN.1 parsing is still required to "seek" to the SPKI, which is not
at a fixed offset in the certificate.  Here is one DANE-authenticated
certificate seen on a live SMTP server:

serial=C3262B13CAB13672
issuer= 
notBefore=Jul 27 14:59:59 2014 GMT
notAfter=Nov 27 14:59:59 3013 GMT
subject= 
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Basically, just the public key, and self-signature, authenticated
via:

    _25._tcp.<mx-hostname>. IN TLSA 3 1 2 (
	    1b97b159e9835555d568841b623cf14a
	    626ccf56fc70b82849cfeb0e802ffc95
	    c4e6620f5848d3d58f6d9ef8cf6b0402
	    55093e7ac946d209d7d72639bd917d92
	)

It does not stricly comply with RFC5280, which forbids empty RDN
sequences for the issuer field, but this does not seem to be a
problem in practice.

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 22 Aug 2018 04:48:07 +0000

Viktor Dukhovni <[email-masked]> writes:

>Some DANE users have reached similar conclusions, though a bit of ASN.1
>parsing is still required to "seek" to the SPKI, which is not at a fixed
>offset in the certificate.

It's actually much simpler than that because you've got a nice unique byte
string, the OID, in front of the key.  My code jumps 64 bytes in and then
scans from there looking for the byte string corresponding to SEQUENCE { RSA
OID, NULL }.  What follows is the public key, you skip the wrapper bytes and
grab the two integer values that follow.

>  41   32:     SEQUENCE {
>  43   13:       UTCTime 27/07/2014 14:59:59 GMT
>  58   15:       GeneralizedTime 27/11/3013 14:59:59 GMT
>         :       }

Yeah, seen those sorts of things too, my code has special-case handling to
clip validTo at 32-bit INT_MAX - 1 if it sees long lifetimes (getting
pedantic, it's actually 2036 since some embedded libraries have problems with
time_t values too close to INT_MAX).

>It does not stricly comply with RFC5280, which forbids empty RDN sequences
>for the issuer field, but this does not seem to be a problem in practice.

Yup.  If all you're doing is a string search for the RSA OID, no-one cares
what else is or isn't present.

Peter.

---

From: Wang Haiguang <[email-masked]>
Date: Wed, 22 Aug 2018 08:40:13 +0000

Hi, all.

Regarding the raw public, I would like to contribute a few words for you to think about it. 

Raw public key is useful for IoT networks due to the constraint of bandwidth and processing capability of devices. A normal certificate takes about a few hundred bytes while an raw public key can be less than one hundred bytes. 

The raw public with TLS can be used together with EAP framework to perform mutual authentication between device and server, i.e. raw public key with EAP-TLS. It not only saves transmission bandwidth, but also simplify the implementation at device side. 

Currently we are collaborate with some leading telecom operator on a solution of using raw public key with EAP-TLS. However, with the normal raw public, the server side need to maintain a table that maps the public key and identity at server side, which can be huge. 

To solve this issue, we are investigating of using identity-based cryptography (i.e. ECCSI in RFC 6507) to eliminate  the huge mapping table. So far it looks good. 

Authentication for IoT could be another huge usage scenarios for TLS, it is expected to have more than 50 billion iot devices deployed in the next 10 years. It is good opportunity to extend the usage of TLS.

Currently, 3GPP has already enable the support for using EAP-TLS in the 5G neworks. Please find the most recent 5G security specification http://www.3gpp.org/ftp/Specs/archive/33_series/33.501/. It has been specified in the Annex B. 

We hope the scope of raw public key with TLS can be extended in the future.  

Regards.

Haiguang Wang
________________________________________
From: TLS [[email-masked]] on behalf of Peter Gutmann [[email-masked]]
Sent: Wednesday, 22 August, 2018 9:55:47 AM
To: <[email-masked]>
Subject: Re: [TLS] null auth ciphers for TLS 1.3?

Peter.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 22 Aug 2018 08:09:07 -0700

>Is there any known actual use of raw public keys for TLS?

I know of a case where TLS (aka SSL) was not used because of the 
lack of support for raw public keys. This work is 20 years old, 
but I'm not sure the situation has changed very much.

The E programming language for distributed applications uses 
remote object references of the form <key-fingerprint, 
objectID), where the key-fingerprint is the hash of the object 
supporting environment -- called a "Vat", and objectID is a 
large secret number.

The Vats use a communication protocol called "Vat TP" 
<http://www.erights.org/elib/distrib/vattp/CommSystemOverview.html> 
to support remote object invocation.

TL:DR
As part of setting up a connection, the target Vat sends its 
public key and the initiating Vat checks the hash of that key. 
The connection parameters are validated by a signature over the 
entire connection dialog. Once the hash has authenticated the 
public key and the signature has validated the connection, the 
initiating Vat can safely send the objectID.

There is a writeup explaining why SSL was not used <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html>

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | There's nothing so clear as  | Periwinkle
(408)356-8506      | a design you haven't written | 16345 
Englewood Ave
www.pwpconsult.com | down.    - Dean Tribble      | Los Gatos, 
CA 95032

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 22 Aug 2018 16:58:26 +0000

Hi Eric,

In response to your 2 questions below:

  1.  Should they be marked "Recommended" in the registry?
[NCW] No, these cipher suites should not be “Recommended” in the registry.

  1.  Should the TLS WG spend time reviewing these documents?
[NCW] I am not sure what you mean (intent-wise) by the question.  Given there has been good feedback in the TLS WG thread.. that we will react to and update the draft accordingly; we can certainly include other applicable use cases as noted by some in the thread.  Lastly, we’d like to the draft published as informational as we expect those with appropriate use cases to employ these ciphers.  So, procedurally, I think some review of (and authors updating) the draft would be warranted?

Warm regards, Nancy

From: TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Tuesday, August 21, 2018 at 11:20
To: "<[email-masked]>" <[email-masked]>
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni <[email-masked]<mailto:[email-masked]>> wrote:

> On Aug 21, 2018, at 1:29 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
>

-Ekr

--
--
        Viktor.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 22 Aug 2018 17:43:35 +0000

Hi Geoff and Richard,
Thanks for raising these points….please see below for my comments:

From: Richard Barnes <[email-masked]>
Date: Tuesday, August 21, 2018 at 07:06
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [TLS] integrity only ciphersuites

On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating <[email-masked]<mailto:[email-masked]>> wrote:

* Anything that relies on EncryptedExtensions should probably not be
used.
[NCW] Thanks for raising this; I will have to review these and perhaps update the draft with appropriate consideration for them.

[NCW] I’m not sure the quantifiable ease is significant (unless the session ticket has been weakly encrypted by the server); but we can certainly add that into the security considerations.

[NCW] From an attack perspective, your description seems to imply selective message blocking which am not sure would be easily achieved in the use cases we listed as breaking the connection would likely imply a session teardown as well.

I'm agnostic w.r.t. confidentiality of application data -- we've historically been bad at making decision about what does / does not need to be confidential, but hey, it's your data.
[NCW] This is an unfortunate truth :-P

However, the EE / NST arguments Geoff make here seem pretty compelling to me.  They indicate to me that if a mechanism is defined where application data is not encrypted, records that contain non-application data still need to be encrypted.  That of course blows away the "code footprint" argument, and it's not trivial to implement given how the application_data content type has been overloaded in 1.3.

ISTM that in order to do this at all elegantly, you'd have to abandon using application_data records for application data, since those have to be encrypted for the above reasons), and instead either:

Unfortunately the former approach would require a Standards Action.  So maybe the latter is the way to go.
[NCW] I need to review the EE to ascertain the need for this….that is, if these indeed need to be encrypted as well as mac’d….

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Aug 2018 17:07:56 -0400

Since we're talking about bare public keys / not verifying certificates
again, a brief reminder:

https://tools.ietf.org/html/draft-barnes-dane-uks-00

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Aug 2018 17:15:06 -0400

> On Aug 23, 2018, at 5:07 PM, Richard Barnes <[email-masked]> wrote:
> 
> Since we're talking about bare public keys / not verifying certificates again, a brief reminder:
> 

Yes, what do you want to do with that draft?  The conclusions for
HTTPS are correct.  For SMTP, UKS surely does not apply, one can
already direct one's SMTP traffic to a different server by just
pointing MX records there...  Ditto for protocols that use SRV
indirection.

So I'd support moving that forward, but perhaps with a more
nuanced set of conditions on when host name checks must not
be skipped.

-- 
	Viktor.