Re: [TLS] raw public keys in the wild?

[Peter Gutmann]

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

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

Re: [TLS] raw public keys in the wild?

[Viktor Dukhovni]

On Wed, Aug 22, 2018 at 01:55:47AM +, Peter Gutmann wrote:

> Viktor Dukhovni  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).

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-
MIIE1TCCAr2gAwIBAgIJAMMmKxPKsTZyMA0GCSqGSIb3DQEBCwUAMAAwIBcNMTQw
NzI3MTQ1OTU5WhgPMzAxMzExMjcxNDU5NTlaMAAwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQC200I1aOkqnrr48PS/MLULQM0QSyCUqvzo07G4Fcwkun+V
tYWS6dWXcNP9s8mRutWFXcZtmIvDs3l0p0HG9N8UU7uQIXJxuuJWAwoLqdvVktOQ
WE7rpItRgNtfVibPmyaoLkLfVBSGTh+tspxXVBZ6OSWjs5CX63CSBCcQtv2ecE+y
AuL6bZDrmgxkPDGGTJiZRwB1ttC7gAITx0OXJOwePrEc1se33vzou8bYIHQWCSct
FxelpEHQ9mDeooT65I3dHph+GXWkh1IYRdltOT4ssmQaEzcmP3KMff4u1ibXzDeq
Bkov6rwPAF/VMHnoESFkA7mR5dpHa31D5l4g6B0dHj24V2IBmBNbzKifa9I04G+G
uKydifHpJ7n4Vc6iijMrrDplwPsSuPdaR6bqg4CID8rU1dxiXAjZz+bK/jIAnuPA
U5kho8lPZgf8YeIgGAF/Yd3hcrX9w5cjKlG/QlhkDStOzIWgXgFSK3tG8GMZm6Ne
LHAjNqOpOrNgLq14aJbOpEzqE3cCl8RVgvP9O/P0ZU7dO/7S3dDaKeg+3anjxhbb
6/iQctxUNxcVyUMf3p1bAl4DqT54dRVNvIS/oH5KaH0rxsW12gmL80VugiuLvuld
t7Pw6A0EjOO4yiMd3BAJCS4evyNMZ75kwZD9YlcX1DPmHUxw11j2F17SS9UfmwID
AQABo1AwTjAdBgNVHQ4EFgQUmMab1SBcHagxOb14ETf/va1bvVkwHwYDVR0jBBgw
FoAUmMab1SBcHagxOb14ETf/va1bvVkwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQsFAAOCAgEAjUcd319j7Nt7o6OmUNB29RqG2iG/eE1Mq++vob7ppSkgawWjiIUO
Vxec5oz1h8cHo3vtffQDB1putL+c220zJK5NDjkGVJ5xaPZdWOkZ/+/i5Xypudoh
3RQZ2MFrq679L4YUuY+/d3W4B8wKYooAmMT7Duzv9xGICgUO75vAmOA5R8CDr1r2
qj2PLF2xlbSToYa/HbFFkeV/b2OrWc8DTsA3/s6fLc1koYFiAHkyTbBDLlhux3n3
tnS+yWXGL9DpuFZg1EZI2G3asoFZqfSUjMSf9qsWb/EE5+kquwQfTcXC4AuwYNgc
MVnaxjJsd4vb53eITRVFyeq4lVrT1l8Z7c1dhA0wdXCso5ptg/68YPq7K0jXEutK
40C/AVapDdT8SYhwawokNujC3epsZ89e0gp6MbiSk3z1jJGO6dk57B/ymAw91TMz
U72xY7YY4yDGUCrxCVBdiGl2kTihwUdxCRJ1baAXcq3meEAY0wQEcDq/dEUMSHp7
/gr9/8uu94VQ+uIjc4dU6oB+yV/agD+vBDpY2EskdVigxZQKuI5iFX4+2kGoooAb
xkMDriyM/MeD3zjfuBLSrMEQtGZ1d8ilb0kWxCcEwv5SpO9ihiUA584C501syGCD
H0y62RuD2sxdv4k3BKeFYt5NLE7QE8TNgVFKsAdTlW9Cni4yEnscwcM=
-END CERTIFICATE-

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

_25._tcp.. IN TLSA 3 1 2 (
1b97b159e983d568841b623cf14a
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.

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

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

[Peter Gutmann]

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

Re: [TLS] integrity only ciphersuites

[Peter Gutmann]

Salz, Rich  writes:

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

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.


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

Re: [TLS] null auth ciphers for TLS 1.3?

[Peter Gutmann]

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

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

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-02.txt

[Nick Sullivan]

tlswg,

After incorporating feedback from the working group, we have published
draft 02 of Delegated Credentials. It contains the following changes from
draft -01:

 (*) indicates changes to the wire protocol.
- Change public key type. (*)
- Change DelegationUsage extension to be NULL and define its object
identifier.
- Drop support for TLS 1.2.
- Add the protocol version and credential signature algorithm to the
Credential structure. (*)
- Specify undefined behavior in a few cases: when the client receives a DC
without indicated support; when the client indicates the extension in an
invalid protocol version; and when DCs are sent as extensions to
certificates other than the end-entity certificate.

Nick

On Fri, Aug 17, 2018 at 11:19 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title   : Delegated Credentials for TLS
> Authors : Richard Barnes
>   Subodh Iyengar
>   Nick Sullivan
>   Eric Rescorla
> Filename: draft-ietf-tls-subcerts-02.txt
> Pages   : 12
> Date: 2018-08-17
>
> Abstract:
>The organizational separation between the operator of a TLS server
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism by
>which operators may delegate their own credentials for use in TLS,
>without breaking compatibility with clients that do not support this
>specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-02
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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

[Martin Thomson]

On Wed, Aug 22, 2018 at 12:07 AM Richard Barnes  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.

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

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

[Blumenthal, Uri - 0553 - MITLL]

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  wrote:
> 
> 
> 
>> On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni  
>> wrote:
>> 
>> 
>> > On Aug 21, 2018, at 1:29 PM, Ted Lemon  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. 
> 
> 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
> 
> 
>> 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.
> 
> 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
> 
> 
>> 
>> -- 
>> -- 
>> Viktor.
>> 
>> ___
>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] null auth ciphers for TLS 1.3?

[David Benjamin]

On Tue, Aug 21, 2018 at 1:34 PM Viktor Dukhovni 
wrote:

>
>
> > On Aug 21, 2018, at 2:18 PM, Eric Rescorla  wrote:
> >
> >> As for TLS 1.3, it is indeed missing both null encryption and null
> >> 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
>
> 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.
>

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

Re: [TLS] null auth ciphers for TLS 1.3?

[Eric Rescorla]

On Tue, Aug 21, 2018 at 11:33 AM, Viktor Dukhovni 
wrote:

>
>
> > On Aug 21, 2018, at 2:18 PM, Eric Rescorla  wrote:
> >
> >> As for TLS 1.3, it is indeed missing both null encryption and null
> >> 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
>
> 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.
>

Yes. TLS 1.3 explicitly does not support those.



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

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

-Ekr


> --
> Viktor.
>
> ___
> 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] null auth ciphers for TLS 1.3?

[Viktor Dukhovni]

> On Aug 21, 2018, at 2:18 PM, Eric Rescorla  wrote:
> 
>> As for TLS 1.3, it is indeed missing both null encryption and null
>> 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

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.

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

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

[Eric Rescorla]

On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni 
wrote:

>
>
> > On Aug 21, 2018, at 1:29 PM, Ted Lemon  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.


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


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

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



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

[Viktor Dukhovni]

> On Aug 21, 2018, at 1:29 PM, Ted Lemon  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.

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

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

[Jack Visoky]

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

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Tuesday, August 21, 2018 1:56 PM
To: Jack Visoky 
Cc: Salz, Rich ; Fries, Steffen 
; ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

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 
mailto:jmvis...@ra.rockwell.com>> wrote:
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:mel...@fugue.com]
Sent: Tuesday, August 21, 2018 1:39 PM
To: Jack Visoky mailto:jmvis...@ra.rockwell.com>>
Cc: Salz, Rich 
mailto:40akamai@dmarc.ietf.org>>; Fries, 
Steffen mailto:steffen.fr...@siemens.com>>; 
ncamwing=40cisco@dmarc.ietf.org; 
tls@ietf.org
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 
mailto:jmvis...@ra.rockwell.com>> 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:tls-boun...@ietf.org] On Behalf 
Of Salz, Rich
Sent: Tuesday, August 21, 2018 1:12 PM
To: Fries, Steffen mailto:steffen.fr...@siemens.com>>
Cc: ncamwing=40cisco@dmarc.ietf.org; 
tls@ietf.org
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]


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?


___
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 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:rs...@akamai.com]
Sent: Tuesday, August 21, 2018 1:46 PM
To: Jack Visoky ; Salz, Rich 
; Fries, Steffen 
Cc: ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
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.

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

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

[Ted Lemon]

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

> 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:mel...@fugue.com]
> *Sent:* Tuesday, August 21, 2018 1:39 PM
> *To:* Jack Visoky 
> *Cc:* Salz, Rich ; Fries, Steffen <
> steffen.fr...@siemens.com>; ncamwing=40cisco@dmarc.ietf.org;
> tls@ietf.org
> *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 
> 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:tls-boun...@ietf.org] *On Behalf Of *Salz, Rich
> *Sent:* Tuesday, August 21, 2018 1:12 PM
> *To:* Fries, Steffen 
> *Cc:* ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> 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?
>
>
>
>
> ___
> 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 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:mel...@fugue.com]
Sent: Tuesday, August 21, 2018 1:39 PM
To: Jack Visoky 
Cc: Salz, Rich ; Fries, Steffen 
; ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
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 
mailto:jmvis...@ra.rockwell.com>> 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:tls-boun...@ietf.org] On Behalf 
Of Salz, Rich
Sent: Tuesday, August 21, 2018 1:12 PM
To: Fries, Steffen mailto:steffen.fr...@siemens.com>>
Cc: ncamwing=40cisco@dmarc.ietf.org; 
tls@ietf.org
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]


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?


___
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

[Salz, 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.

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

Re: [TLS] integrity only ciphersuites

[Bill Frantz]

On 8/21/18 at 7:24 AM, stephen.farr...@cs.tcd.ie (Stephen 
Farrell) wrote:



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.


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?

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

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

[Ted Lemon]

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 
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:tls-boun...@ietf.org] *On Behalf Of *Salz, Rich
> *Sent:* Tuesday, August 21, 2018 1:12 PM
> *To:* Fries, Steffen 
> *Cc:* ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> 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?
>
>
>
> ___
> 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 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:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Tuesday, August 21, 2018 1:12 PM
To: Fries, Steffen 
Cc: ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]


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?

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

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

[Ted Lemon]

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 
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:tls-boun...@ietf.org] *On Behalf Of *Fries, Steffen
> *Sent:* Tuesday, August 21, 2018 12:54 PM
> *To:* Salz, Rich 
> *Cc:* ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
>
>
> On 21. Aug 2018, at 18:13, Salz, Rich  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. :)
>
>
>
> 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.
>
> ___
> 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

[Salz, Rich]

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?

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

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

[Jack Visoky]

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:tls-boun...@ietf.org] On Behalf Of Fries, Steffen
Sent: Tuesday, August 21, 2018 12:54 PM
To: Salz, Rich 
Cc: ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]



On 21. Aug 2018, at 18:13, Salz, Rich 
mailto:rs...@akamai..com>> 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. :)

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

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

[Jack Visoky]

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:stephen.farr...@cs.tcd.ie] 
Sent: Tuesday, August 21, 2018 12:38 PM
To: Ted Lemon ; Jack Visoky 
Cc: ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites



On 21/08/18 17:15, Ted Lemon wrote:
> 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?

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

Re: [TLS] integrity only ciphersuites

[Fries, Steffen]

On 21. Aug 2018, at 18:13, Salz, Rich 
mailto:rs...@akamai..com>> 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. :)

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

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

[Stephen Farrell]

On 21/08/18 17:15, Ted Lemon wrote:
> 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?

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.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

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 
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.
>
>
>
> I’m happy to clarify any of these points further if needed.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* Ted Lemon [mailto:mel...@fugue.com]
> *Sent:* Tuesday, August 21, 2018 10:58 AM
> *To:* Jack Visoky 
> *Cc:* Andreas Walz ; tls@ietf.org; ncamwing=
> 40cisco@dmarc.ietf.org
> *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 
> wrote:
>
> (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:tls-boun...@ietf.org] *On Behalf Of *Andreas Walz
> *Sent:* Tuesday, August 21, 2018 9:37 AM
> *To:* tls@ietf.org
> *Cc:* ncamwing=40cisco@dmarc.ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> +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 

Re: [TLS] integrity only ciphersuites

[Salz, Rich]

Ø  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. :)

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

Re: [TLS] integrity only ciphersuites

[Ted Lemon]

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

[Fries, Steffen]

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

Re: [TLS] integrity only ciphersuites

[Salz, Rich]

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

Re: [TLS] integrity only ciphersuites

[Fries, Steffen]

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  On Behalf Of Andreas Walz
Sent: Dienstag, 21. August 2018 15:37
To: tls@ietf.org
Cc: ncamwing=40cisco@dmarc.ietf.org
Subject: 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 
>>> mailto:kathleen.moriarty.i...@gmail.com>> 
>>> 08/21/18 3:20 PM >>>


Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL 
> mailto:u...@ll.mit.edu>> wrote:
>
> "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.

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
>
>> On Aug 21, 2018, at 07:42, Stephen Farrell 
>> mailto:stephen.farr...@cs.tcd.ie>> wrote:
>>
>>
>>
>>> 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.
>>>
>>> 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.
>>
>> 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 

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

[Jack Visoky]

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:mel...@fugue.com]
Sent: Tuesday, August 21, 2018 10:58 AM
To: Jack Visoky 
Cc: Andreas Walz ; tls@ietf.org; 
ncamwing=40cisco@dmarc.ietf.org
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 
mailto:jmvis...@ra.rockwell.com>> wrote:
(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:tls-boun...@ietf.org] On Behalf 
Of Andreas Walz
Sent: Tuesday, August 21, 2018 9:37 AM
To: tls@ietf.org
Cc: ncamwing=40cisco@dmarc.ietf.org
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]

+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; 

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

[Ted Lemon]

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

> (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:tls-boun...@ietf.org] *On Behalf Of *Andreas Walz
> *Sent:* Tuesday, August 21, 2018 9:37 AM
> *To:* tls@ietf.org
> *Cc:* ncamwing=40cisco@dmarc.ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> +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  08/21/18 3:20 PM
> >>>
>
>
> Sent from my mobile device
>
> > On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
> >
> > "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.
>
> 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
> >
> >> 

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

[Jack Visoky]

(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:tls-boun...@ietf.org] On Behalf Of Andreas Walz
Sent: Tuesday, August 21, 2018 9:37 AM
To: tls@ietf.org
Cc: ncamwing=40cisco@dmarc.ietf.org
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]

+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 
>>> mailto:kathleen.moriarty.i...@gmail.com>> 
>>> 08/21/18 3:20 PM >>>


Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL 
> mailto:u...@ll.mit.edu>> wrote:
>
> "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.

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
>
>> On Aug 21, 2018, at 07:42, Stephen Farrell 
>> mailto:stephen.farr...@cs.tcd.ie>> wrote:
>>
>>
>>
>>> 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.
>>>
>>> In following the new IANA rules, we have posted the draft
>>> 

Re: [TLS] integrity only ciphersuites

[Stephen Farrell]

On 21/08/18 14:36, Andreas Walz wrote:
> 
> 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. 

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.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Blumenthal, Uri - 0553 - MITLL]

On Aug 21, 2018, at 10:16, Stephen Farrell  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

> On 21/08/18 13:10, Blumenthal, Uri - 0553 - MITLL wrote:
>> "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.)

I disagree, but I see your point.

>> 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 think I and others addressed those issues. Or tried to,
> 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
> when people have started out thinking they don't need
> confidentiality, it turned out later that they did.

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.




>>> On Aug 21, 2018, at 07:42, Stephen Farrell
>>>  wrote:
>>> 
>>> 
>>> 
 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.
 
 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.
>>> 
>>> 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 

Re: [TLS] integrity only ciphersuites

[Stephen Farrell]

Hiya,

On 21/08/18 13:10, Blumenthal, Uri - 0553 - MITLL wrote:
> "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.)

> 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 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
> 
> Sent from my iPhone
> 
>> On Aug 21, 2018, at 07:42, Stephen Farrell
>>  wrote:
>> 
>> 
>> 
>>> 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.
>>> 
>>> 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.
>> 
>> 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 

Re: [TLS] integrity only ciphersuites

[Richard Barnes]

On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating  wrote:

> "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?
>

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


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

[Andreas Walz]

+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  08/21/18 3:20
PM >>>


Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL
 wrote:
> 
> "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.

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
> 
>> On Aug 21, 2018, at 07:42, Stephen Farrell
 wrote:
>> 
>> 
>> 
>>> 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.
>>> 
>>> 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.
>> 
>> 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>> 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 

Re: [TLS] integrity only ciphersuites

[Bill Frantz]

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

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

Re: [TLS] integrity only ciphersuites

[Kathleen Moriarty]

Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> "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.

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
> 
>> On Aug 21, 2018, at 07:42, Stephen Farrell  wrote:
>> 
>> 
>> 
>>> 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.
>>> 
>>> 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.
>> 
>> 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 

Re: [TLS] integrity only ciphersuites

[Viktor Dukhovni]

> On Aug 21, 2018, at 12:32 AM, Viktor Dukhovni  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.

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.

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

Re: [TLS] integrity only ciphersuites

[Blumenthal, Uri - 0553 - MITLL]

"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  wrote:
> 
> 
> 
>> 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.
>> 
>> 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.
> 
> 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 wy 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 

Re: [TLS] integrity only ciphersuites

[Stephen Farrell]

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

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




0x5AB2FAF17B172BEA.asc
Description: