Below is a Doodle poll link for scheduling the TLS interim meeting
wherein we will discuss next steps for
draft-ietf-tls-dnssec-chain-extension. Please fill out the poll so
that we may find a time that works best for everyone.
https://doodle.com/poll/bhqrve377grmtbwh
Thanks,
Chris, Joe, and S
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 fr
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 ke
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), an
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 su
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 n
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 it
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
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
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
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 TL
> 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.
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-c
> 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,
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 fo
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 cas
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
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 a
* 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 rath
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 s
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 us
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:
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
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/ma
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 Bes
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
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
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
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:
Ø 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
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 b
Ø 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 su
* 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?
___
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
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 conce
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
com
(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.
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
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/cy
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-de
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
+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:
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 authentica
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
> 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 clien
"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, a
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
47 matches
Mail list logo
