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

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

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

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?

Re: [TLS] integrity only ciphersuites

> 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

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

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

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

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

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

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

Re: [TLS] integrity only ciphersuites

"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

Re: [TLS] integrity only ciphersuites

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:

Re: [TLS] integrity only ciphersuites

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

Re: [TLS] integrity only ciphersuites

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,

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

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

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

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

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

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

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

[TLS] integrity only ciphersuites

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

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

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 >

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

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

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

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

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

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

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

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 >

[TLS] Request to register value in TLS extension registry

[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: