Hi,
- The draft has a lot of claims regarding benefits:
"strong requirement for low latency."
"minimize the cryptographic algorithms are prioritized"
"important for latency to be very low."
"pay more for a sensor with encryption capability"
"come with a small runtime memory footprint an
Hi,
TLS 1.3 has several stated security properties. One of them is "Protection of
endpoint identities". EAP-TLS 1.3 (up until version -13) was written with the
assumption that this property holds. Other uses of TLS 1.3 might also rely on
the property to hold. With draft-camwinget-tls-ts13-macci
With Alan's comments, I think we are down to 3 alternatives:
(1a). Use close_notify alert as protected success.
Use error alerts as protected failure.
- Forbid close_notify except as success indication
- Mandate Error alert before EAP-Failure
- Forbid all use of user_cancelle
On Wed, 10 Feb 2021, 10:19 John Mattsson, wrote:
> I think RFC8446bis needs to state that this property only holds for cipher
> suites with confidentiality.
>
All cipher suites defined by RFC8446bis (Appendix B.4) provide
confidentiality. The property always holds.
>
___
Hiya,
I realise it's not proposed as a wg document, but
fwiw, I think John is quite correct below. The only
additional point I'd add is that I've seen cases
over the years where the fact that confidentiality
really *is* required only became clear when people
actually considered how to attack sys
On Wed, 10 Feb 2021 at 12:09, Ben Smyth wrote:
> On Wed, 10 Feb 2021, 10:19 John Mattsson, 40ericsson@dmarc.ietf.org> wrote:
>
>> I think RFC8446bis needs to state that this property only holds for
>> cipher suites with confidentiality.
>>
>
> All cipher suites defined by RFC8446bis (Appendi
* Previous versions of TLS explicitly offered a null cipher (wherein
encryption consists of the identity operation, i.e., the data is not
encrypted). These modes have been deprecated in TLS 1.3.
These modes have been *removed* in TLS 1.3 Further, the only ciphers in the
RFC provide authent
Agreed. With that said, I don't think it would hurt to add some text. John,
would you like to provide a PR?
-Ekr
On Wed, Feb 10, 2021 at 8:11 AM Salz, Rich wrote:
>
>- Previous versions of TLS explicitly offered a null cipher (wherein
>encryption consists of the identity operation, i.e
Hi John,
> I don't think this draft should be published as long as it gives the idea
> that sacrificing confidentiality has significant benefits for latency,
> memory, processing power, and cost. This is in general not the case.
There definitely are cases where this is true, and cases where it i
Hi Stephen,
I believe the case of the robotic arm which paints cars would be a reasonable
example of a case where confidentiality of data is not required. I fully admit
that it's not generalizable to all robotic arms painting all cars, but I do
believe it holds for many of these cases. At the r
I oppose this draft. Use earlier versions of TLS that do have auth-only and
integrity cipher suites.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hiya,
On 10/02/2021 22:56, Jack Visoky wrote:
Hi Stephen,
I believe the case of the robotic arm which paints cars would be a
reasonable example of a case where confidentiality of data is not
required. I fully admit that it's not generalizable to all robotic
arms painting all cars, but I do bel
I also do not support this draft. Don't all of these proposals come with
claims about efficiency and latency? It's getting old. Sorry if that sounds
cynical.
thanks,
Rob
On Wed, Feb 10, 2021 at 1:15 AM John Mattsson wrote:
> Hi,
>
> - The draft has a lot of claims regarding benefits:
>
> "str
Hi Stephen,
Thanks for elaborating.
>From the general standpoint I think we can both agree an attacker can more
>easily cause more harm if packets can be modified than not modified,
>especially in the use case examples. Now of course I can't and don't claim in
>all cases of a robotic arm (or a
> I would just like to recognize that there are some situations where it isn't
> needed.
Can you explain why TLS 1.2 isn't good enough for your needs?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> On Feb 10, 2021, at 11:57 PM, Jack Visoky
> wrote:
>
> I would just like to recognize that there are some situations where it isn't
> needed.
One classic case where Postfix supports TLS 1.[0-2] NULL ciphers
is loopback TLS (process to process communication via [127.0.0.1]
or a unix-domain so
Hiya,
First, a caveat - I don't know and am guessing how these
systems are built (if you have pointers, those'd be good
to see), but nonetheless...
On 11/02/2021 01:57, Jack Visoky wrote:
Hi Stephen,
Thanks for elaborating.
From the general standpoint I think we can both agree an attacker ca
On Thu, Feb 11, 2021 at 12:40:51AM -0200, Viktor Dukhovni wrote:
>
> There is merit in keeping the combinatorial complexity of TLS 1.3
> as small as possible, reducing implementation attack surface, ...
>
> The key question, that is difficult to answer is whether the right
> balance is adequately
18 matches
Mail list logo
