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

[Wang Haiguang]

Hi, all.

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

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

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

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

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

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

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

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

Regards.

Haiguang Wang

From: TLS [tls-boun...@ietf.org] on behalf of Peter Gutmann 
[pgut...@cs.auckland.ac.nz]
Sent: Wednesday, 22 August, 2018 9:55:47 AM
To: 
Subject: Re: [TLS] null auth ciphers for TLS 1.3?

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

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

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

[Bill Frantz]

On 8/22/18 at 6:55 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:


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


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


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


The Vats use a communication protocol called "Vat TP" 
 
to support remote object invocation.


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


There is a writeup explaining why SSL was not used 


Cheers - Bill

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


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

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

[Nancy Cam-Winget (ncamwing)]

Hi Eric,

In response to your 2 questions below:

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



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

Warm regards, Nancy

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



On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni 
mailto:ietf-d...@dukhovni.org>> wrote:


> On Aug 21, 2018, at 1:29 PM, Ted Lemon 
> mailto:mel...@fugue.com>> 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] integrity only ciphersuites

[Nancy Cam-Winget (ncamwing)]

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

From: Richard Barnes 
Date: Tuesday, August 21, 2018 at 07:06
To: "geo...@geoffk.org" 
Cc: "ncamw...@cisco.com" , "" 
Subject: Re: [TLS] integrity only ciphersuites


On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating 
mailto:geo...@geoffk.org>> wrote:
"Nancy Cam-Winget \(ncamwing\)" 
mailto:40cisco@dmarc.ietf.org>> 
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.
[NCW] Thanks for raising this; I will have to review these and perhaps update 
the draft with appropriate consideration for them.


* 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.
[NCW] I’m not sure the quantifiable ease is significant (unless the session 
ticket has been weakly encrypted by the server); but we can certainly add that 
into the security considerations.

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


I 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.
[NCW] This is an unfortunate truth :-P

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

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

- 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.
[NCW] I need to review the EE to ascertain the need for this….that is, if these 
indeed need to be encrypted as well as mac’d….

--Richard


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

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

[Benjamin Kaduk]

No need to submit a new one -- I can edit it as needed.

-Ben

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

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