Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

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.
> 
> If you don't need CT--I'm not entirely persuaded by Viktor's argument but I
> agree that the need is probably less than with WebPKI--then it seems like
> the technical work is done. If you do need CT, then probably your next stop
> is secdispatch, what with trans being closed.

Agreed, with the already mentioned clarification that the "CT" in
question would be DNSSEC-Transparency not X.509 CT, except when the DANE
usages are PKIX-{TA,EE} where the usual WebPKI rules also apply.

The "DNSSEC-Transparency" would log eTLD delegation security and any
delegations above that (root to TLD, TLD to 2LD eTLD public suffix,
...).  The viability or a such a system has not been established, nor is
there even a sufficiently detailed potential design for evaluation.

It is not clear between wider DNSSEC adoption and availability of a CT
analogue which is the cart and which is the horse.  I don't think that
lack such an analogue is presently a real obstacle to wider deployment
of DNSSEC.  If I'm mistaken, perhaps this is something that could be
explored sooner.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Eric Rescorla]

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 but I
agree that the need is probably less than with WebPKI--then it seems like
the technical work is done. If you do need CT, then probably your next stop
is secdispatch, what with trans being closed.

-Ekr


On Mon, Nov 28, 2022 at 5:32 PM Viktor Dukhovni 
wrote:

> 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
> > > suggest via rfc9162).
> >
> > How do you propose we prevent CT from being DoSed by a deluge of
> > self-signed certificates?
>
> There isn't a known viable approach to combine the existing CT system
> with DANE.  On the other hand, the actual certificates are not what one
> would want to log anyway.  Instead one would only want to log DS RRsets
> or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
> 2LD, 3LD, ...  suffixes operated by TLD registries).  Clients that
> contribute to CT logs would need to run validating resolvers and
> log signed delegations.
>
> Once a NODATA proof is recorded, no more such proofs are logged until
> the delegation is again signed.
>
> So spamming can only happen as a result of repeated changes to a zones
> DS RRset, including its deletion.  Similar spamming would be possible by
> obtaining certificates from many CAs and rolling them over as frequently
> as possible.
>
> So long as a domain's DS RRset is not forged by the parent eTLD, what
> (self-signed) certificates its TLSA records vouch for is an internal
> matter, that is easily audited internally.  Monitor your DNS, and don't
> sign rogue TLSA records.
>
> --
> 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] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

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
> > suggest via rfc9162).
> 
> How do you propose we prevent CT from being DoSed by a deluge of
> self-signed certificates?

There isn't a known viable approach to combine the existing CT system
with DANE.  On the other hand, the actual certificates are not what one
would want to log anyway.  Instead one would only want to log DS RRsets
or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
2LD, 3LD, ...  suffixes operated by TLD registries).  Clients that
contribute to CT logs would need to run validating resolvers and
log signed delegations.

Once a NODATA proof is recorded, no more such proofs are logged until
the delegation is again signed.

So spamming can only happen as a result of repeated changes to a zones
DS RRset, including its deletion.  Similar spamming would be possible by
obtaining certificates from many CAs and rolling them over as frequently
as possible.

So long as a domain's DS RRset is not forged by the parent eTLD, what
(self-signed) certificates its TLSA records vouch for is an internal
matter, that is easily audited internally.  Monitor your DNS, and don't
sign rogue TLSA records.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

[Martin Thomson]

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: https://github.com/martinthomson/sslkeylogfile/pull/1

One benefit of moving this under IETF change control is that we can have those 
conversations about how to manage this better.  To Stephen's point, the idea 
that you might negotiate an extension when this is enabled is an interesting 
one.  I don't think that it needs to be large in order to have the intended 
effect (if the intended effect is punitive in nature, then that creates certain 
disincentives around compliance).  There are many cases where I think it would 
be beneficial to have the presence of this known to both entities.  The 
challenge of course is that this is primarily of benefit to the client only - 
the server cannot unilaterally signal that it has this machinery engaged.

(Another thing to note is that the qlog work in the QUIC working group has 
lesser, but broadly similar properties.  It would be good to share what we 
learn from this exercise.)

On Tue, Nov 29, 2022, at 03:22, Andrei Popov wrote:
> 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 for adoption of 
> draft-thomson-tls-keylogfile
>
> 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, but then I'd argue that it should be an Informational 
>> RFC.
>
> The I-D has: "Intended status: Informational" (for some reason the 
> datatracker is unable to determine this).
>
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7C4d4695c5433c4186eed608dad17465a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052595136932049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0WqfX2eGL7cXMwCbYEOegEEnpRNXtdyFcDC3QBjMOe8%3D=0
>
> ___
> 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] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> 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 by a deluge of
self-signed certificates?

Best,

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

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

[Andrei Popov]

> 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 
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile


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 cat-picture payload?)

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

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[Stephen Farrell]

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 cat-picture payload?)

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

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 into last mile barriers (as you reported at
IETF114 IIRC, is there now a paper you can link to?).

Once the client has TLSA records be it directly from DNS, or
server-facilitated via a TLS extension, at that point what's trusted
should not depend materially on how the TLSA records were obtained.

So back to the OP's question, what appears to be missing here?  It seems
to me that "3 1 1" TLSA records are sufficient to allow self-signed
certificates to validate, indeed this is already quite common in TLS for
SMTP.  The only known nit is that for an HTTP browser one needs to heed
a potential UKS issue, and so the advice in RFC7671 to ignore the
hostname in certificates validated via a TLSA "3 1 1" record is not
appropriate for "https" in browsers that support following remotely
supplied links, redirects, care about cross-origin issues, ...

In simpler protocols that just move data between a client and server,
the RFC7671 semantics for "3 1 1" records reduce the potential for
operator error (seen with low, but non-zero frequency for "2 1 1"
records, where some MX hosts now and then sport certificates that don't
match their names).

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

[Andrei Popov]

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 for adoption of draft-thomson-tls-keylogfile

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, but then I'd argue that it should be an Informational 
> RFC.

The I-D has: "Intended status: Informational" (for some reason the datatracker 
is unable to determine this).



-Ilari

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7C4d4695c5433c4186eed608dad17465a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052595136932049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0WqfX2eGL7cXMwCbYEOegEEnpRNXtdyFcDC3QBjMOe8%3D=0

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

[TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Ollie]

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 certificates. Is 
this best discussed here in TLS, or perhaps over at HTTP?

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).

I've set up an example site and GitHub repo with more details:
- https://justselfsigned.org
- https://github.com/OllieJC/justselfsigned.org

It'd be great to get your thoughts and support to progress this.

Thanks,
Ollie___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[Ilari Liusvaara]

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, but then I'd argue that it should be an
> Informational RFC.

The I-D has: "Intended status: Informational" (for some reason
the datatracker is unable to determine this).



-Ilari

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

Re: [TLS] [UNVERIFIED SENDER] Re: New Version Notification for draft-kampanakis-tls-scas-latest-01.txt

[Kampanakis, Panos]

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 this data is not straightforward, I 
must say.


From: John Mattsson 
Sent: Thursday, November 24, 2022 6:04 AM
To: Kampanakis, Panos ; tls@ietf.org
Cc: Bytheway, Cameron 
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: New Version Notification for 
draft-kampanakis-tls-scas-latest-01.txt


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi,

I think this is great work and something the TLS WG should adopt and work on. 
Reducing the total number of bytes is very important not only in constrained 
IoT, but also in TLS based EAP methods, and in applications where handshake 
time to completion is important.

I quicky read the -02 draft. It seems to be in a good shape. Some comments:

- I think it would be good if the draft described how it works with 
draft-ietf-tls-subcerts. While the latest version of draft-ietf-tls-subcerts 
talks about "delegated credential" and not certifcates, they are commonly 
refered to as subcerts.
- I think draft-kampanakis-tls-scas-latest could considered allowing 
suppressing also the end-entity certificate for use cases when 
draft-ietf-tls-subcerts is used.

Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Kampanakis, Panos 
mailto:kpanos=40amazon@dmarc.ietf.org>>
Date: Friday, 4 March 2022 at 16:42
To: tls@ietf.org mailto:tls@ietf.org>>
Cc: Bytheway, Cameron mailto:byth...@amazon.com>>
Subject: Re: [TLS] New Version Notification for 
draft-kampanakis-tls-scas-latest-01.txt
Hi all,

The updated -01 version fixes a couple of nits identified by Ilari, removes the 
needs for two different tlsflags, one each direction, and does not require an 
acknowledgement of the ICA suppression tlsflag based on discussions about the 
tlsflags draft 
https://mailarchive.ietf.org/arch/msg/tls/SIvCO_ZFmNfTEeyiuZOcdBzTdAo/

There are more issues we are tracking based on discussions in this list 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-24c7ac234ac8e19f=1=76ac0dba-b0c6-4ac8-9538-5faabd060cb2=https%3A%2F%2Fgithub.com%2Fcsosto-pk%2Ftls-suppress-intermediates%2Fissues

-Original Message-
From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: Friday, March 4, 2022 10:34 AM
To: Bas Westerbaan mailto:b...@cloudflare.com>>; Bytheway, 
Cameron mailto:byth...@amazon.com>>; Martin Thomson 
mailto:m...@lowentropy.net>>; Kampanakis, Panos 
mailto:kpa...@amazon.com>>
Subject: [EXTERNAL] New Version Notification for 
draft-kampanakis-tls-scas-latest-01.txt

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



A new version of I-D, draft-kampanakis-tls-scas-latest-01.txt
has been successfully submitted by Panos Kampanakis and posted to the IETF 
repository.

Name:   draft-kampanakis-tls-scas-latest
Revision:   01
Title:  Suppressing CA Certificates in TLS 1.3
Document date:  2022-03-04
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-kampanakis-tls-scas-latest-01

Abstract:
   A TLS client or server that has access to the complete set of
   published intermediate certificates can inform its peer to avoid
   sending certificate authority certificates, thus reducing the size of
   the TLS handshake.




The IETF Secretariat


___
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] Call for adoption of draft-thomson-tls-keylogfile

[Andrei Popov]

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 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 be an Informational RFC.

Standards-track RFC that promotes the export of TLS secrets in clear-text sends 
the wrong message, can (and will) be used to push TLS stack vendors to 
implement this.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Salz, Rich
Sent: Monday, November 28, 2022 10:54 AM
To: Sean Turner ; TLS List 
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

I support adoption.

I assume the wireshark folk(s), etc., will review ...

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7Ce5d4a41309dd44fe5e2108dad172043a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052584901610518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=ffuQE0lqf5IzkYWzizCPKXA4lEHU6e9Nh5kJ4gwd998%3D=0

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

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[Andrei Popov]

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.

Standards-track RFC that promotes the export of TLS secrets in clear-text sends 
the wrong message, can (and will) be used to push TLS stack vendors to 
implement this.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Salz, Rich
Sent: Monday, November 28, 2022 10:54 AM
To: Sean Turner ; TLS List 
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

I support adoption.

I assume the wireshark folk(s), etc., will review ...

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7Ce5d4a41309dd44fe5e2108dad172043a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052584901610518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=ffuQE0lqf5IzkYWzizCPKXA4lEHU6e9Nh5kJ4gwd998%3D=0

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

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[Salz, Rich]

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

[TLS] tls@ietf115: minutes

[Sean Turner]

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

Re: [TLS] draft-ietf-tls-batch-signing

[Sean Turner]

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 filed [4]. Libsodium seems to offer best checks 
> for batch verification. Currently testing other libraries that offer support 
> for EdDSA.
> 
> 1) Chalkias, Garillot, and Nikolaenko "Taming the many EdDSAs" 
> https://eprint.iacr.org/2020/1244
> 
> 2) Brendel, Cremers, Jackson, and Zhao "The Provable Security of Ed25519: 
> Theory and Practice" https://eprint.iacr.org/2020/823
> 
> 3) https://datatracker.ietf.org/doc/html/rfc8032
> 
> 4) https://www.rfc-editor.org/errata_search.php?rfc=8032_status=0
> 
> ___
> 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

[TLS] Fwd: IETF WG state changed for draft-ietf-tls-batch-signing

[Sean Turner]

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 draft-ietf-tls-batch-signing has been changed to "Dead
> WG Document" from "WG Document" by Sean Turner:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-batch-signing/
> 
> 

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

[TLS] The TLS WG has placed draft-thomson-tls-keylogfile in state "Call For Adoption By WG Issued"

[IETF Secretariat]

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
https://www.ietf.org/mailman/listinfo/tls

[TLS] Call for adoption of draft-thomson-tls-keylogfile

[Sean Turner]

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 on 12 December 
2022. If do not support adoption, please indicate why.

Cheers,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS AAD length usage clarification?

[Achim Kraus]

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 used.

> My understanding is that the DTLSCiphertext.length =
length_of_DTLSInnerPlaintext  + MAC Length i.e 16B for AES-GCM;

I haven't implemented EtM, so I'm not sure about that. I would guess,
the length of the explicit nounce is also included.

You may check your implementation (AEAD and CBC MtE) against:

https://github.com/eclipse-californium/californium#interop-server

https://github.com/Mbed-TLS/mbedtls/pull/6264 (AFAIK, that question
about EtM was raised also there.)

and

https://github.com/eclipse/tinydtls/tree/feature/connection_id
(client only, AEAD only)

best regards
Achim



Am 28.11.22 um 16:25 schrieb Cunningham, Andrew:

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:
https://www.rfc-editor.org/rfc/rfc9146.html#section-5

length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized
DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.

The enc_content field is the encrypted form of the serialized
DTLSInnerPlaintext structure which is covered by the DTLSCiphertext.length

My understanding is that the DTLSCiphertext.length =
length_of_DTLSInnerPlaintext  + MAC Length i.e 16B for AES-GCM;

The protection layer definitions use these variables interchangeable in
the DTLS 1.2 CID specification which is leading to some confusion (at
least in my head);

https://www.rfc-editor.org/rfc/rfc9146.html#section-5


Block Ciphers;

     MAC(MAC_write_key,

     seq_num_placeholder +

     tls12_cid +

     cid_length +

     tls12_cid +

     DTLSCiphertext.version +

     epoch +

     sequence_number +

     cid +

*_    length_of_DTLSInnerPlaintext +_*

     DTLSInnerPlaintext.content +

     DTLSInnerPlaintext.real_type +

     DTLSInnerPlaintext.zeros

     );

Encrypt then MAC;

MAC(MAC_write_key,

     seq_num_placeholder +

     tls12_cid +

     cid_length +

     tls12_cid +

     DTLSCiphertext.version +

     epoch +

     sequence_number +

     cid +

*_    DTLSCiphertext.length +_*

     IV +

     ENC(cont

AEAD Ciphers;

     additional_data = seq_num_placeholder +

   tls12_cid +

   cid_length +

   tls12_cid +

   DTLSCiphertext.version +

   epoch +

   sequence_number +

   cid +

*_  length_of_DTLSInnerPlaintext;_*

So we have some cases where the length_of_DTLSInnerPlaintext is used in
the additional data and another case for Encrypt/then/MAC where the DTLS
header length (DTLSCiphertext.length) as seen on the wire is used in the
additional data.

This seems to be slightly different for TLS1.3 which always the
TLSCiphertext.length field.
https://www.rfc-editor.org/rfc/rfc8446.html#section-5.2


I am trying to understand why we use different lengths for different
cryptographic algorithms for DTLS and diverge from how TLS1.3 implements
things.  Was there some security reason for selected of
length_of_DTLSInnerPlaintext vs DTLSCiphertext.length in the additional
data for the various protection modes?

Thanks in advance,

Regards

Andrew

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution by
others is strictly prohibited. If you are not the intended recipient,
please contact the sender and delete all copies.


___
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

[TLS] DTLS AAD length usage clarification?

[Cunningham, Andrew]

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: 
https://www.rfc-editor.org/rfc/rfc9146.html#section-5
length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized 
DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.

The enc_content field is the encrypted form of the serialized 
DTLSInnerPlaintext structure which is covered by the DTLSCiphertext.length

My understanding is that the DTLSCiphertext.length = 
length_of_DTLSInnerPlaintext  + MAC Length i.e 16B for AES-GCM;

The protection layer definitions use these variables interchangeable in the 
DTLS 1.2 CID specification which is leading to some confusion (at least in my 
head);

https://www.rfc-editor.org/rfc/rfc9146.html#section-5



Block Ciphers;

MAC(MAC_write_key,

seq_num_placeholder +

tls12_cid +

cid_length +

tls12_cid +

DTLSCiphertext.version +

epoch +

sequence_number +

cid +

length_of_DTLSInnerPlaintext +

DTLSInnerPlaintext.content +

DTLSInnerPlaintext.real_type +

DTLSInnerPlaintext.zeros

);





Encrypt then MAC;

MAC(MAC_write_key,

seq_num_placeholder +

tls12_cid +

cid_length +

tls12_cid +

DTLSCiphertext.version +

epoch +

sequence_number +

cid +

DTLSCiphertext.length +

IV +

ENC(cont



AEAD Ciphers;

additional_data = seq_num_placeholder +

  tls12_cid +

  cid_length +

  tls12_cid +

  DTLSCiphertext.version +

  epoch +

  sequence_number +

  cid +

  length_of_DTLSInnerPlaintext;





So we have some cases where the length_of_DTLSInnerPlaintext is used in the 
additional data and another case for Encrypt/then/MAC where the DTLS header 
length (DTLSCiphertext.length) as seen on the wire is used in the additional 
data.



This seems to be slightly different for TLS1.3 which always the 
TLSCiphertext.length field. 
https://www.rfc-editor.org/rfc/rfc8446.html#section-5.2



I am trying to understand why we use different lengths for different 
cryptographic algorithms for DTLS and diverge from how TLS1.3 implements 
things.  Was there some security reason for selected of 
length_of_DTLSInnerPlaintext vs DTLSCiphertext.length in the additional data 
for the various protection modes?



Thanks in advance,

Regards

Andrew

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls