Hi,
I think it would be good if the draft gave a recommendation on how to format
the EUI-64. My feeling from googling all the specification I could find is that
the most common way to format a EUI-64 as a text string is with dashes and with
capital hex characters. This is what is currently opti
+1
From: Uta on behalf of Dmitry Belyavsky
Date: Sunday, 14 March 2021 at 11:05
To: "Salz, Rich"
Cc: "uta@ietf.org"
Subject: Re: [Uta] Requesting adoption of draft-rsalz-use-san
I support the adoption of this draft
On Sun, Mar 14, 2021 at 12:32 AM Salz, Rich
mailto:40akamai@dmarc.ietf.
Hi,
There has been a lot requests from people in different working groups for souce
code to try out C509 certificates. I just released my example implementation of
a DER X509 to CBOR C509 encoder written in Rust.
CBOR encoded X509 (RFC 5280) is one of the main future work item for the COSE
WG.
Hi,
Some sections mention "server" while other sections does not state anything,
therefor applying to both client and server. I think the draft needs to be very
clear on this point.
I saw that there was a discussion on client certs and that some client certs
are built with CN and cannot be eas
Hi,
I promised to send some information to the list regarding security
considerations for long connections. I think the (D)TLS 1.3 is lacking
considerations on this as well so I made an issue for RFC8446bis.
https://github.com/tlswg/tls13-spec/issues/1245
The info in the issue is probably a go
, John Mattsson wrote:
>
> I promised to send some information to the list regarding security
> considerations for long connections. I think the (D)TLS 1.3 is
> lacking considerations on this as well so I made an issue for
> RFC8446bis.
>
> https://protect2.fireeye.com/v1/ur
Hi,
Two comments:
- In some applications using mutually authenticated TLS, e.g., between nodes in
5G core networks or in mesh networks there is basically no difference between
the client and the server. It would be very good if the document states that
for such use cases the recommendations ap
Ryan Sleevi wrote:
On Sat, Nov 20, 2021 at 6:58 AM John Mattsson
mailto:40ericsson@dmarc.ietf.org>>
wrote:
- In some applications using mutually authenticated TLS, e.g., between nodes in
5G core networks or in mesh networks there is basically no difference between
the client a
Hi,
In EMU WG there was a stong consensus to mandate revocation checking in EAP-TLS
1.3. Mandatory OCSP Stapling was suggested by someone as a way to achieve this.
The transition from EAP-TLS 1.2 to EAP-TLS 1.3 made this possible. The
mandatory to use OCSP Stapling was softened after comments f
24 January 2022 at 17:19
To: uta@ietf.org , t...@ietf.org
Subject: Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +0000, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often
Hi,
I reviwed the whole document. Looks fine in general. Some comments:
- "Those who implement and deploy TLS and DTLS, in particular versions 1.2 or
earlier of these protocols"
Delete "or earlier". As these versions are "MUST NOT negotiate". Might be good
to mention this deprecation in the i
Hi,
I quickly looked at -06. Looks ready for WGLC. Two high level comments.
- I think QUIC should be mentioned already in section 1.1 and mentioned
everytime DTLS is mentioned Otherwise the document feels old already when it is
published. QUIC already makes up a huge part of internet traffic (o
Hi,
I think this should be published asap. A BCP would be even better.
IETF is as usual late:
- NIST requires support TLS 1.3 since 1 Jan 2024. Not just in new deployments
but everywhere.
- 3GPP requires TLS 1.3 everywhere in the core network since the first 5G
specification (Rel-15, 2018).
-
I would be very supportive of such approach. I think the scope should cover
mTLS in general, not just cross-organization. The term mTLS is not even defined
in IETF, in fact the TLS WG has previously used mTLS for at two other things.
It would be good to a document to refer to for implementation
inducing any major traffic overhead (nor CPU or
memory overhead). Transition to more secure cipher suites (TLS 1.2 with
AES-GCM or ChaCha20-Poly1305) actually reduces both traffic and processing
overhead.
I plan to request time for presentation in Toronto.
John Mattsson
On 04/07/14 23:32
, "Ivan Ristić" wrote:
>On 04/07/2014 23:48, John Mattsson wrote:
>> We have submitted a new draft on TLS overhead. That TLS causes overhead
>>is
>> a common argument regarding TLS (and other security protocols). If TLS
>> adds much overhead has recently be
ant to make the point that low overhead and high security
actually goes hand in hand.
>- Given the recent trend in turning on TLS for MTA-MTA
> traffic, I believe it may be possible to get some good
> numbers from folks who've done that, so asking for that
> would be good.
Goo
I reviewed "draft-ietf-uta-tls-attacks-01” (I have not read the recent
review comments on the list). Some comments:
- General
The title is "Summarizing Current Attacks on TLS and DTLS" but there is no
section on
Attacks on DTLS. This needs to be fixed.
Either you make two separate sections or you
6.2]
What is an "attack against DLP"? DLP is a mathematical problem without any
promised
security level...
Maybe something like "No efficient general method for solving DLP is known, so
DH protect
against attackers if sufficiently large parameters are chosen.
[Section 6.2]
There is an ongoing discussion in CDNi on how to define a TLS profile for all
the CDNi interfaces. The suggestion from the CDNi chair is:
“The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be followed.”
I have commented that the aim of the TLS BCP is “improving the security of
dep
I am happy to announce that TLS 1.3 is already mandatory to support for all
uses of TLS in 3GPP 5G (and also LTE, 3G systems that are updated to the latest
release). Release 15 makes TLS 1.3 mandatory for networks and Release 16 makes
TLS 1.3 mandatory also for MEs (i.e. mobile phones) while rem
Hi,
The draft "Using EAP-TLS with TLS 1.3" (draft-ietf-emu-eap-tls13-03) specifies
the use of EAP-TLS with TLS 1.3:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13
https://github.com/emu-wg/draft-ietf-emu-eap-tls13
In Bangkok the EMU WG decided to analyse if some of the known attacks on TL
: "internet-dra...@ietf.org"
Date: Monday, 9 March 2020 at 21:19
To: John Mattsson , John Mattsson
, Joel Höglund , Joel Hoglund
, Göran Selander , Martin
Furuhed , Göran Selander
, Shahid Raza
Subject: New Version Notification for
draft-mattsson-tls-cbor-cert-compress-00.txt
Hi,
I think this is important work. RFC 7925 is a very useful document. While
working on
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04
https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00
I'll deep dived into the certificate profiles specified in Section 4.4 o
profile in
RFC 7925 and if any clarifications or updates are needed. This is likely best
discussed in UTA which may take up work on a TLS/DTLS 1.3 update of RFC 7925.
https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01
Cheers,
John
-Original Message-
From: John Mattsson
Date
n
and hopefully have interop testing in the COSE WG.
Cheers,
John
-Original Message-
From: TLS on behalf of Hannes Tschofenig
Date: Friday, 3 April 2020 at 14:20
To: John Mattsson ,
"t...@ietf.org" , "uta@ietf.org"
Subject: Re: [TLS] CBOR Certificate Compressio
, brotli, zstd) is that the
new algorithm only works for a specific subset of RFC 5280, namely RFC 7925.
Cheers,
John
-Original Message-
From: Sean Turner
Date: Saturday, 11 April 2020 at 04:44
To: John Mattsson
Cc: "t...@ietf.org" , "uta@ietf.org" , Hannes
Tsc
Hi,
I have reviewed the draft and I have some comments. If these are fixed I think
the document is ready for publishing.
Major:
>This SHOULD be TLS 1.3 or TLS 1.2, depending on the circumstances
>described in the above paragraphs.
This could be interpretated as TLS 1.1 can be supported on a SHO
2024 at 15:26
To: John Mattsson , uta@ietf.org
Subject: Re: [Uta] Re: WGLC for draft-ietf-uta-require-tls13-02
>Any new protocol that uses TLS MUST specify as its default TLS 1.3.
This does not age well if TLS 1.4 is done. I suggest changing to 1.3 or later.
We did have a short discussion in per
29 matches
Mail list logo
