Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Judson Wilson]

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


On Mon, Aug 20, 2018 at 9:20 PM Peter Gutmann 
wrote:

> Lyndon Nerenberg  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.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Editorial Errata Reported] RFC8422 (5468)

[Masato Gosui]

If a new errata proposing the PDU change is needed, I gladly submit it.

--
Masato Gosui

On Fri, Aug 17, 2018 at 10:25:47AM +0200, Simon Josefsson wrote:
> I think “namedCurve” is better, it matches ASN.1 usage.

So you want me to change the PDU to be "namedCurve" instead?

-Ben

> /Simon
> 
> > 17 aug. 2018 kl. 04:21 skrev RFC Errata System 
:
> > 
> > The following errata report has been submitted for RFC8422,
> > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer 
Security (TLS) Versions 1.2 and Earlier".
> > 
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5468
> > 
> > --
> > Type: Editorial
> > Reported by: Masato Gosui 
> > 
> > Section: 5.4
> > 
> > Original Text
> > -
> >   namedCurve: Specifies a recommended set of elliptic curve domain
> > 
> > Corrected Text
> > --
> >   namedcurve: Specifies a recommended set of elliptic curve domain
> > 
> > Notes
> > -
> > This fixes mismatched names of the variable "namedcurve" in the 
"Structure of this message" paragraph.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --
> > RFC8422 (draft-ietf-tls-rfc4492bis-17)
> > --
> > Title   : Elliptic Curve Cryptography (ECC) Cipher Suites 
for Transport Layer Security (TLS) Versions 1.2 and Earlier
> > Publication Date: August 2018
> > Author(s)   : Y. Nir, S. Josefsson, M. Pegourie-Gonnard
> > Category: PROPOSED STANDARD
> > Source  : Transport Layer Security
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Viktor Dukhovni]

> On Aug 20, 2018, at 4:57 PM, Eric Rescorla  wrote:
> 
> 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

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Peter Gutmann]

Lyndon Nerenberg  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Judson Wilson]

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


On Mon, Aug 20, 2018 at 5:02 PM Lyndon Nerenberg  wrote:

> 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)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Lyndon Nerenberg]

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)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Geoffrey Keating]

"Nancy Cam-Winget \(ncamwing\)"  writes:

> 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.

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?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Judson Wilson]

How are these devices authenticating?


On Mon, Aug 20, 2018 at 4:14 PM Nancy Cam-Winget (ncamwing)  wrote:

> Hi Eric,
>
> Thanks for the prompt feedback!  Please see further comments/questions
> below:
>
>
>
> *From: *Eric Rescorla 
> *Date: *Monday, August 20, 2018 at 13:58
> *To: *"ncamw...@cisco.com" 
> *Cc: *"tls@ietf.org" 
>
>
> *Subject: *Re: [TLS] integrity only ciphersuites
>
>
>
>
>
>
>
> On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
> ncamwing=40cisco@dmarc.ietf.org> 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.
>
> [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….
>
>
>
> So, overall, this doesn't seem very compelling..
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
> Warm regards, Nancy (and Jack)
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Nancy Cam-Winget (ncamwing)]

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

From: Eric Rescorla 
Date: Monday, August 20, 2018 at 13:58
To: "ncamw...@cisco.com" 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] integrity only ciphersuites



On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) 
mailto:ncamwing=40cisco@dmarc.ietf.org>>
 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.
[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….

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

-Ekr




Warm regards, Nancy (and Jack)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Mike Bishop]

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  On Behalf Of Eric Rescorla
Sent: Monday, August 20, 2018 1:58 PM
To: Nancy Cam-Winget (ncamwing) 
Cc: tls@ietf.org
Subject: Re: [TLS] integrity only ciphersuites



On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) 
mailto:ncamwing=40cisco@dmarc.ietf.org>>
 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




Warm regards, Nancy (and Jack)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

On Mon, Aug 20, 2018 at 5:36 PM, Jack Visoky 
wrote:

> 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.
>

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?


> 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.
>

I would really encourage you to take a look at MUD (Manufacturer Usage
Description)  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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Eric Rescorla]

On Mon, Aug 20, 2018 at 2:36 PM, Jack Visoky 
wrote:

> 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.
>

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


> 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:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: Monday, August 20, 2018 4:58 PM
> To: Nancy Cam-Winget (ncamwing) 
> Cc: tls@ietf.org
> 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)  40cisco@dmarc.ietf.org> 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
>
>
>
>
> Warm regards, Nancy (and Jack)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Jack Visoky]

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:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday, August 20, 2018 4:58 PM
To: Nancy Cam-Winget (ncamwing) 
Cc: tls@ietf.org
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) 
 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



 
Warm regards, Nancy (and Jack)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Eric Rescorla]

On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
ncamwing=40cisco@dmarc.ietf.org> 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




>
> Warm regards, Nancy (and Jack)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] integrity only ciphersuites

[Nancy Cam-Winget (ncamwing)]

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)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state "Call For Adoption By WG Issued"

[Hubert Kario]

On Friday, 17 August 2018 19:33:19 CEST IETF Secretariat wrote:
> The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state
> Call For Adoption By WG Issued (entered by Sean Turner)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/

I support the adoption.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

[Short, Todd]

I support adoption.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 17, 2018, at 1:32 PM, Sean Turner 
mailto:s...@sn3rd.com>> wrote:

At the TLS@IETF102 session, there seemed to be some interest in adopting 
draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to 
determine whether there is WG consensus to adopt this draft as a WG item.  If 
you would like for this draft to become a WG document and you are willing to 
review it as it moves through the process, then please let the list know by 
2359UTC 20180831.  If you are opposed to this being a WG document, please say 
so (and say why).

Note that we will suggest replacing “diediedie" with “deprecate" in the adopted 
draft’s name to address the naming comment raised during the meeting.

Thanks,
Chris, Joe and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Drop "1.x" from future TLS version names?

[Loganaden Velvindron]

On Mon, Aug 20, 2018 at 7:28 PM, Tony Arcieri  wrote:
> Apologies if the last thing people want to talk about right now is the next
> version of TLS.
>
> There was much discussion about bumping TLS 1.3's version number to "TLS 4"
> or thereabouts (so as to be higher than "SSLv3"). The ship has sailed on
> that and it is "TLS 1.3".
>
> I think there was widespread agreement that TLS 1.3 represented something a
> bit more substantial than a minor version bump, and a desire to have a TLS
> version number bigger than the SSL version number lest people get confused
> and deploy SSLv3 instead of TLS 1.3.
>
> Modest proposal: TLS 1.4 => TLS 4
>
> I bring this up so soon because I think a lot of the pushback regarding
> doing this before was due to changing the version so late in the development
> cycle.

I think that it's too late for that now.

>
> --
> Tony Arcieri
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Drop "1.x" from future TLS version names?

[Tony Arcieri]

Apologies if the last thing people want to talk about right now is the next
version of TLS.

There was much discussion about bumping TLS 1.3's version number to "TLS 4"
or thereabouts (so as to be higher than "SSLv3"). The ship has sailed on
that and it is "TLS 1.3".

I think there was widespread agreement that TLS 1.3 represented something a
bit more substantial than a minor version bump, and a desire to have a TLS
version number bigger than the SSL version number lest people get confused
and deploy SSLv3 instead of TLS 1.3.

Modest proposal: TLS 1.4 => TLS 4

I bring this up so soon because I think a lot of the pushback regarding
doing this before was due to changing the version so late in the
development cycle.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state "Call For Adoption By WG Issued"

[Nikos Mavrogiannopoulos]

On Fri, 2018-08-17 at 10:33 -0700, IETF Secretariat wrote:
> The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in
> state
> Call For Adoption By WG Issued (entered by Sean Turner)
> 
> The document is available at
> 
https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/

I support the adoption.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Request to register value in TLS extension registry

[Peter Gutmann]

[CC'd to the main TLS list, since I don't know how many people are on the tls-
 reg-review one and therefore wouldn't otherwise see this, and the archives
 and discussion for that are all non-public]

Now that RFC 8447 is published, I'd like to request the addition of extension
ID 26 for TLS-LTS:

https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/

This extension has been waiting for quite some time for the publication of
8447, so it's already in use by implementations.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls