On Mon, Nov 28, 2022 at 06:23:36PM -0800, Eric Rescorla wrote:
> Thanks for the elaboration, Viktor.
>
> I think the TL;DR here is that this isn't TLS-relevant work at present.
> Either you get the certs directly or you get them via RFC 9102 but in
> either case, TLS has the appropriate support.
Thanks for the elaboration, Viktor.
I think the TL;DR here is that this isn't TLS-relevant work at present.
Either you get the certs directly or you get them via RFC 9102 but in
either case, TLS has the appropriate support.
If you don't need CT--I'm not entirely persuaded by Viktor's argument
On Tue, Nov 29, 2022 at 01:04:14AM +0100, Bas Westerbaan wrote:
> > In essence, I'm proposing that user agents should trust a fully DNSSEC
> > domain with a TLS certificate set up using DANE, along with changes to CT
> > log submission process to allow self-signed certificates (looking to
> >
I personally have no intention of making this PS (or to otherwise water down
recommendations against it).
I do have some interest in doing what can be done to make this less of a
hazard. You will see that I took John's suggest to more directly proscribe its
use:
>
> In essence, I'm proposing that user agents should trust a fully DNSSEC
> domain with a TLS certificate set up using DANE, along with changes to CT
> log submission process to allow self-signed certificates (looking to
> suggest via rfc9162).
>
How do you propose we prevent CT from being DoSed
> If there were some technical means to ensure that this was less likely to be
> abused, I'd like it more.
Perhaps require key update prior to secrets export
-Original Message-
From: TLS On Behalf Of Stephen Farrell
Sent: Monday, November 28, 2022 2:20 PM
To: Sean Turner ; TLS List
I'm ok with adoption so long as we include sufficient
caveats along the way (and then add more caveats just
in case:-)
If there were some technical means to ensure that this
was less likely to be abused, I'd like it more. (Could
we e.g. require inclusion of a TLS extension that has a
100kB
On Mon, Nov 28, 2022 at 12:27:07PM -0800, Eric Rescorla wrote:
> How much of the TLS part of this objective is achieved by RFC 9102?
Well, RFC9102 is at a different layer. It provides a mechanism for
clients to obtain a TLSA RRset by other means than direct DNS lookup,
because that often runs
Does an Informational draft require WG adoption? If the goal isn't to switch to
the Standards track, I have no concerns.
Cheers,
Andrei
-Original Message-
From: TLS On Behalf Of Ilari Liusvaara
Sent: Monday, November 28, 2022 11:11 AM
To: TLS List
Subject: [EXTERNAL] Re: [TLS] Call
Hi folks,
I'm new to the I-D/RFC process so apologies for any naivety!
Firstly, I've done a quick search for any commentary around this but haven't
found anything specific - but let me know if I've likely missed something.
I want to propose a way for a user agent to trust self-signed
On Mon, Nov 28, 2022 at 07:02:20PM +, Andrei Popov wrote:
>
> I oppose adoption of draft-thomson-tls-keylogfile. The stated goal
> was to find a permanent, discoverable location for this document,
> other than NSS project's repository. Perhaps it's fine to create an
> RFC for this purpose,
Thanks John.
Good points about draft-ietf-tls-subcerts. I am tracking it in git and will
update.
Before bringing the draft up for discussion again, we are trying to quantify
the "stale ICA cache causing TLS connection failures for the web", as this was
a concern the group brought up. Getting
Corrected typo inline.
-Original Message-
From: Andrei Popov
Sent: Monday, November 28, 2022 11:02 AM
To: 'Salz, Rich' ; Sean Turner
; TLS List
Subject: RE: [TLS] Call for adoption of draft-thomson-tls-keylogfile
I oppose adoption of draft-thomson-tls-keylogfile. The stated goal was
I oppose adoption of draft-thomson-tls-keylogfile. The stated goal was to find
a permanent, discoverable location for this document, other than NSS project's
repository. Perhaps it's fine to create an RFC for this purpose, but then I'd
argue that it should not be an Informational RFC.
I support adoption.
I assume the wireshark folk(s), etc., will review ...
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Draft of minutes are posted:
https://datatracker.ietf.org/meeting/115/materials/minutes-115-tls-202211100930-00
Please submit any changes by Friday (12/2).
Cheers,
spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Please note that this I-D has been abandoned.
spt
> On Nov 10, 2022, at 06:29, Benson Muite wrote:
>
> The above draft has expired. However, if there is still interest in it, the
> EdDSA specification will need to be updated based on findings in [1] and [2].
> An erratum to [3] has been
FYI
> Begin forwarded message:
>
> From: IETF Secretariat
> Subject: IETF WG state changed for draft-ietf-tls-batch-signing
> Date: November 10, 2022 at 06:07:24 EST
> To: ,
> Resent-From:
> Resent-To: j...@salowey.net, c...@heapingbits.net, sean+i...@sn3rd.com
>
>
> The IETF WG state of
The TLS WG has placed draft-thomson-tls-keylogfile in state
Call For Adoption By WG Issued (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
___
TLS mailing list
TLS@ietf.org
Hi!
At TLS@IETF115, the sense of the room was that there was WG support to adopt
draft-thomson-tls-keylogfile [1]. This message is to judge consensus on
whether the WG should adopt draft-thomson-tls-keylogfile. Please indicate
whether you do or do not support adoption of this I-D by 2359UTC
Hi Andrew,
> length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized
DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.
Yes, the original plaintext, the original record type and the padding.
For AEAD and CBC without EtM, that "length_of_DTLSInnerPlaintext" is
Greetings all.
I was wondering could someone help clarify my understanding on the use of
length fields for DTLS 1.2 + CID with respect to TLS1.3, specifically with the
additional data input to the AEAD functions.
If we start with the DTLS1.2 + CID's RFC:
22 matches
Mail list logo
