[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[Eric Rescorla]

These are all fair points, and it's possible we don't need to do anything
with the transcript.

I don't think we need to resolve this before adoption, I just wanted to
make sure that I said something now to make sure people weren't surprised
later.

-Ekr


On Tue, May 21, 2024 at 6:46 AM David Benjamin 
wrote:

> Off the cuff, folding it into the transcript sounds tricky, since existing
> TLS servers won't know to do it, and, as with any other DNS hints, we need
> to accommodate the DNS being out of sync with the server. It'll also be
> more difficult to deploy due to needing changes in the TLS stack and
> generally require much, much tighter coordination between DNS and TLS. I'd
> like for that coordination to be more viable (see my comments on the
> .well-known draft), but I don't think we're there yet.
>
> But I'm certainly open to continue discussing it and this problem space!
> The original version of the draft actually tried a lot harder to handle the
> downgrade story. Rather than mess with the transcript, it defined away all
> the negotiation algorithms where this would be a problem and keyed the
> NamedGroup codepoints to know when you could be guaranteed of the narrower
> server behavior.
>
> My read of the feedback was that people thought this was an unnecessary
> complication and that servers doing a key-share-first selection were doing
> so intentionally because they believed the options roughly equivalent. So I
> took all that out and replaced it with text to that effect.
>
> David
>
>
> On Tue, May 21, 2024, 08:54 Eric Rescorla  wrote:
>
>> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
>> less sure about addressing the basic insecurity of the DNS channel with the
>> approach this draft takes. I don't have a complete thought here, but what
>> if we were to somehow fold the hint into the handshake transcript? I
>> suppose we can sort this out post-adoption, but I'd like the question to be
>> on the table.
>>
>> -Ekr
>>
>>
>> On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:
>>
>>> This is a working group call for adoption
>>> for draft-davidben-tls-key-share-prediction.  This document was presented
>>> at IET 118 and has undergone some revision based on feedback since then.
>>> The current draft is available here:
>>> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
>>> Please read the document and indicate if and why you support or do not
>>> support adoption as a TLS working group item. If you support adoption
>>> please, state if you will help review and contribute text to the document.
>>> Please respond to this call by May 20, 2024.
>>>
>>> Thanks,
>>>
>>> Joe, Deidre, and Sean
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[Eric Rescorla]

I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
less sure about addressing the basic insecurity of the DNS channel with the
approach this draft takes. I don't have a complete thought here, but what
if we were to somehow fold the hint into the handshake transcript? I
suppose we can sort this out post-adoption, but I'd like the question to be
on the table.

-Ekr


On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:

> This is a working group call for adoption
> for draft-davidben-tls-key-share-prediction.  This document was presented
> at IET 118 and has undergone some revision based on feedback since then.
> The current draft is available here:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
> Please read the document and indicate if and why you support or do not
> support adoption as a TLS working group item. If you support adoption
> please, state if you will help review and contribute text to the document.
> Please respond to this call by May 20, 2024.
>
> Thanks,
>
> Joe, Deidre, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [TLS] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 4:30 PM Dennis Jackson  wrote:

> On 01/05/2024 00:07, Watson Ladd wrote:
>
> On Tue, Apr 30, 2024 at 3:26 PM Dennis 
> Jackson 
>  wrote:
> 
>
> Let's assuming for a moment we could a) get most of the world to use ACME (a 
> worthy but challenging goal) and b) get them to configure multiple CAs and 
> receive multiple certificates. We don't need trust expressions to be able to 
> do quick rotations - because we don't ever want to use the old CA. It's just 
> a case of swapping to the new one. There's no need for negotiation.
>
> We've already seen a serious problem with cross-signing happen, where
> Cloudflare is planning to stop using Lets Encrypt. That's because the
> cross-signed cert that let Lets Encrypt work with old Android devices
> expired, with no replacement. Having websites present one chain
> creates a lot of thorny tradeoffs. Either you present a cross-signed
> certificate, or a few, and take the bandwidth hit, or you don't and
> suffer a compatibility hit. This was manageable when signatures were
> small. When they get chonky it will be much less fun.
>
> There's a huge and unexplored design space here that does not require
> trust negotiation. I don't claim any of these ideas are optimal:
>
>- Techniques like abridged certs + cross signs let you mitigate any
>bandwidth impact for recent-ish clients. Given the older clients are going
>to be missing a lot of performance improvements anyway, this doesn't seem
>unacceptable.
>- Root Programs could introduce specific root certs they operate for
>the sole purpose of cross-signing new CAs to speed up their adoption.
>- Clients could have a TLS flag 'My Root Store is very old' which is
>set when X years without a root store update have passed. Alternatively,
>they advertise an explicit age for their root store or the TLS Flag 'My
>Root Store was updated in the past year'.
>
> Wouldn't we also get this last point as a sort of side effect of abridged
certs?

-Ekr


>- I think there may also be some interesting ways to improve Merkle
>Tree Certs to support these use cases without needing trust negotiation but
>that'll have to wait for another thread.
>
> As far as I'm aware there is no need for cooperation in creating a
> cross-signed intermediate: it's a certificate with a public key and
> just a different signer. So Country X could force its sites to include
> that cross-signed intermediate in the grab bag handed to browsers, and
> everything would work as now. Browsers have to tolerate all sorts of
> slop there anyway. I think the sharper concern is that you could block
> traffic without the cert included.
>
> Sincerely,
> Watson Ladd
>
>
> ___
> 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] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 8:37 AM Dennis Jackson  wrote:

> As mentioned above, we have such an extension already insofar as
> indicating support for Delegated Credentials means indicating a desire for
> a very short credential lifetime and an acceptance of the clock skew risks.
>
I agree that DC implicitly says "I think I have an accurate clock". I think
that given
the design of DC it was probably right to merge the "I support DCs" and "I
think
my clock is good enough to support DCs" semantics, but I don't think it's
at all
as natural to do that in the case of CAs, which, after all, could support
both short
and long-lived certificates. As I said earlier, I think the right way to do
that is
with an orthogonal extension [0]



Given how little use its seen, I don't know that its a good motivation for
> Trust Expressions.
>
I agree with you about this.

-Ekr

[0] I also don't think (not that you suggested it) that one should infer
from the client
advertising support for DCs that it has an accurate enough clock for every
purpose.

On 30/04/2024 16:33, Eric Rescorla wrote:
>
>
>
> On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd  wrote:
>
>> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
>> >
>> >
>> > On the narrow point of shorter lifetimes, I don't think the right way
>> to advertise that you have an accurate clock is to advertise that you
>> support some set of root certificates.
>> >
>> > If we want to say that, we should have an extension that actually says
>> you have an accurate clock.
>>
>> That says you *think* you have an accurate clock.
>>
>
> Quite so. However, if servers gate the use of some kind of short-lived
> credential
> on a client signal that the client thinks it has an accurate clock
> (however that
> signal is encoded) and the clients are frequently wrong about that, we're
> going
> to have big problems.
>
> -Ekr
>
>
>
>
>> Sincerely,
>> Watson
>>
>> --
>> Astra mortemque praestare gradatim
>>
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
> ___
> 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] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd  wrote:

> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
> >
> >
> > On the narrow point of shorter lifetimes, I don't think the right way to
> advertise that you have an accurate clock is to advertise that you support
> some set of root certificates.
> >
> > If we want to say that, we should have an extension that actually says
> you have an accurate clock.
>
> That says you *think* you have an accurate clock.
>

Quite so. However, if servers gate the use of some kind of short-lived
credential
on a client signal that the client thinks it has an accurate clock (however
that
signal is encoded) and the clients are frequently wrong about that, we're
going
to have big problems.

-Ekr




> Sincerely,
> Watson
>
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 8:14 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> Of course this is possible in theory, there are no standards police, but
>> this argument overlooks the gargantuan technical and economic costs of
>> deploying this kind of private extension. You'd need to convince a diverse
>> population of implementers on both the client and server side to adopt and
>> enable your thing.
>>
>
> I don't believe my hypothetical private extension would need to be adopted
> by any servers, just clients. And due to power laws, adoption by one or two
> clients would provide visibility into a substantial section of Internet
> traffic.
>
> Can you expand on how this draft enables the more rapid distrust of failed
>> CAs?
>>
>
>  This is described in more detail in section 9.1 of the draft. Currently
> we have the problem that, as long as any older RP relies on a given root,
> subscribers have to keep using it, which means newer RPs have to keep
> trusting it.
>
> I'm confused by this remark. Are there clients which would tolerate a
>> certificate if only it had a longer lifetime? Is there any circumstance in
>> which you would have both a long-life and short-life certificate available,
>> and you would prefer to serve the long-life cert?
>>
>
>  Yes, especially when you push to shorter and shorter lifetimes (say, 1
> day, 1 hour), you start to have the issue that not all clients will have
> sufficiently accurate clocks to verify them. Clients with accurate clocks
> can advertise support for a root that issues short-lived certs while
> clients that don't will not advertise support for this root, and with TE we
> can support both.
>

On the narrow point of shorter lifetimes, I don't think the right way to
advertise that you have an accurate clock is to advertise that you support
some set of root certificates.

If we want to say that, we should have an extension that actually says you
have an accurate clock.

-Ekr



> On Tue, Apr 30, 2024 at 3:57 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> Hi Brendan, Bas,
>> On 30/04/2024 05:17, Brendan McMillion wrote:
>>
>> It seems like, with or without this extension, the path is still the
>> same: you'd need to force a browser to ship with a government-issued CA
>> installed. Nothing about this makes that easier. It /is/ somewhat nice to
>> already have a way to signal that a given client does/doesn't support the
>> government CA -- but you could just as easily do this with a simple
>> extension from the private range, so I'm not sure that was a big blocker.
>>
>> On 30/04/2024 09:13, Bas Westerbaan wrote:
>>
>> No need for a new extension: a government can use a specific signature
>> algorithm for that (say, a national flavour of elliptic curve, or a
>> particular PQ/T hybrid).
>>
>> Of course this is possible in theory, there are no standards police, but
>> this argument overlooks the gargantuan technical and economic costs of
>> deploying this kind of private extension. You'd need to convince a diverse
>> population of implementers on both the client and server side to adopt and
>> enable your thing. This draft if widely implemented as-is would effectively
>> solve that problem for governments by removing a huge architectural
>> roadblock. This is the power of the IETF and why decisions about what TLS
>> extensions to adopt are important. Mark Nottingham has a longer piece
>>  on this view.
>>
>> On 30/04/2024 05:17, Brendan McMillion wrote:
>>
>> On the other hand, this draft solves a number of existing security
>> issues, by allowing more rapid distrust of failed CAs,
>>
>> Can you expand on how this draft enables the more rapid distrust of
>> failed CAs?
>>
>> The roadblock to faster distrust has always been how quickly subscribers
>> of the failed CA are able to migrate. ACME makes this process much easier,
>> but still requires server operators to reconfigure their ACME clients. This
>> draft doesn't improve that situation.
>>
>> An effective technique long-used by Microsoft and Mozilla when
>> distrusting CAs is to ship a distrust-certs-issued-after signal rather than
>> an immediate distrust of all issued certificates. This allows server
>> operators to gradually migrate in line with their usual schedule of
>> certificate renewals rather than forcing a flag day on the world. I
>> understand that at least one further major root program is looking at
>> supporting the same feature.
>>
>> by allowing clients to signal support for short-lived certificates, etc.
>>
>> I'm confused by this remark. Are there clients which would tolerate a
>> certificate if only it had a longer lifetime? Is there any circumstance in
>> which you would have both a long-life and short-life certificate available,
>> and you would prefer to serve the long-life cert?
>>
>


> Best,
>> Dennis
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> 

Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Eric Rescorla]

Hi folks,

I haven't yet formed an opinion on this document yet, but I did want to
observe that calls for adoption are issued by the chairs, not by individual
participants. Of course, anyone can start a thread and comments in this
thread are information for the chairs, but if adoption does happen, it will
be via some separate process.

-Ekr


On Sat, Apr 27, 2024 at 11:42 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> Hi Devon
>
> I support adoption
>
> On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov  40microsoft@dmarc.ietf.org> wrote:
>
>> I support adoption.
>>
>> Cheers,
>>
>> Andrei
>>
>> -Original Message-
>> From: TLS  On Behalf Of Watson Ladd
>> Sent: Friday, April 26, 2024 7:13 PM
>> To: Devon O'Brien 
>> Cc: tls@ietf.org; Bob Beck 
>> Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions
>>
>> On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien > 40google@dmarc.ietf.org> wrote:
>> >
>> > After sharing our first draft of TLS Trust Expressions and several
>> discussions across a couple  IETFs, we’d like to proceed with a call for
>> working group adoption of this draft. We are currently prototyping trust
>> expressions in BoringSSL & Chromium and will share more details when
>> implementation is complete.
>> >
>> >
>> > As we mentioned in our message to the mailing list from January, our
>> primary goal is to produce a mechanism for supporting multiple subscriber
>> certificates and efficiently negotiating which to serve on a given TLS
>> connection, even if that ends up requiring significant changes to the draft
>> in its current state.
>> >
>> >
>> > To that end, we’re interested in learning whether wg members support
>> adoption of this deployment model and the currently-described certificate
>> negotiation mechanism or if they oppose adoption (and why!).
>>
>> We absolutely need to solve the problem and the draft is a good starting
>> point.
>>
>> >
>> >
>> > Thanks!
>> >
>> > David, Devon, and Bob
>> >
>> >
>> > ___
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www/.
>> > ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7CAndrei.Popov%40micr
>> > osoft.com%7C6ca75aa932344f322d9f08dc665fa375%7C72f988bf86f141af91ab2d7
>> > cd011db47%7C1%7C0%7C638497808164901299%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
>> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
>> > 7C=2n8iljUXBtb4Jf%2FZTqN2Nl5j81WoatTYA64c5%2FRoH0A%3D=0
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> ___
>> 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 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] Deprecating Static DH certificates in the obsolete key exchange document

[Eric Rescorla]

Yes.

-Ekr

On Mon, Apr 15, 2024 at 11:14 AM Joseph Salowey  wrote:

> At IETF 119 we had discussion that static DH certificates lead to static
> key exchange which is undesirable.  Although the current draft deprecates
> static DH ciphersuites, it seems that RFC 5246 allows the client to provide
> a certificate with a static DH keypair to provide static parameters in
> (EC)DHE in TLS 1.2 (I don't know of any implementations that do this).
>
> Should the draft deprecate these ClientCertificateTypes and mark the
> entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as
> 'D' discouraged?
>
> Please respond with any comments on this proposal by April 30,2024.
>
> Thanks,
>
> Sean, Deirdre and Joe
> ___
> 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] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

On Thu, Apr 4, 2024 at 7:38 PM Mike Bishop  wrote:

> Ekr, can I ask you to clarify this a little? I fully agree that extensions
> to TLS which support a particular application-layer protocol should be done
> in that protocol’s working group unless and until it’s demonstrated that
> many unrelated applications will need something similar. (At which point,
> it probably makes sense to build the general thing, either in TLS or a new
> WG.) But this isn’t that.
>
>
>
> For something that concerns the TLS exchange itself, the TLS WG does still
> seem like the natural home to me. Where are you suggesting the standards
> work happens instead? Are you suggesting that this should be registered to
> the I-D, or go to a new/different working group? The former path seems like
> it won’t get the review it needs, and I’m not sure any other WGs are
> appropriately chartered for the latter.
>

I'm suggesting it be registered based on the ID.

When you say "get the review it needs", I think that's at the heart of the
question. My position is that the TLS WG (and the IETF generally) should
spend its limited resources on things which are important and likely to
receive wide deployment. Other code points can just be registered and
marked "recommended=N". Of course, they won't get review, but nothing stops
people from registering all kinds of bad ideas without review; that's why
the registries were open.

Here's what would make me interested in seeing the TLS WG spend time on
this: a critical mass of both servers and clients of the type contemplated
here (e.g., search engines or crawlers) who say they would actually use it.

-Ekr


>
>
> Personally, I support adoption for the use case. It sounds like there’s an
> alternative design that might need to be hammered out, but since it appears
> a document may be needed for either path, let’s adopt and argue about that
> later.
>
>
>
> *From:* TLS  *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, April 3, 2024 10:28 AM
> *To:* Watson Ladd 
> *Cc:* Christopher Patton ; TLS
> List 
> *Subject:* Re: [TLS] Adoption call for TLS Flag - Request mTLS
>
>
>
>
>
>
>
> On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd  wrote:
>
>
>
> On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla  wrote:
>
> Adoption should not be required to register a code point [0], as the
> policy is Specification Required.
>
>
>
> I'm mildly negative on adopting this document. What is the reason we need
> to spend WG time on this, rather than just having a code point assignment?
>
>
>
> Well, don't we want to say how this is supposed to work somewhere?
>
>
>
> Why? The attitude I am trying to get away from is that the TLS WG has to
>
> be involved in every extension to TLS. Rather, we should decide what things
>
> are important and spend time on them and then let others extend TLS
> independently
>
> in areas we don't think are important.
>
>
>
> -Ekr
>
>
>
> I doubt this will take much time.
>
>
>
> -Ekr
>
>
>
> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
> should clearly have
>
> a policy which matches 8447 S 7, which is to say that an I-D is sufficient.
>
>
>
>
>
> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
> I'd like to see this problem solved. There was some discussion about
> whether an I-D is needed or all we needed was to register a code point
> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
> happy to review.
>
>
>
> Chris P.
>
>
>
> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>
> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consensus on
> whether there is sufficient support to adopt this I-D.  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> 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 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] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd  wrote:

>
> On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla  wrote:
>
>> Adoption should not be required to register a code point [0], as the
>> policy is Specification Required.
>>
>> I'm mildly negative on adopting this document. What is the reason we need
>> to spend WG time on this, rather than just having a code point assignment?
>>
>
> Well, don't we want to say how this is supposed to work somewhere?
>

Why? The attitude I am trying to get away from is that the TLS WG has to
be involved in every extension to TLS. Rather, we should decide what things
are important and spend time on them and then let others extend TLS
independently
in areas we don't think are important.

-Ekr


> I doubt this will take much time.
>
>>
>> -Ekr
>>
>> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
>> should clearly have
>> a policy which matches 8447 S 7, which is to say that an I-D is
>> sufficient.
>>
>>
>> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton > 40cloudflare@dmarc.ietf.org> wrote:
>>
>>> I'd like to see this problem solved. There was some discussion about
>>> whether an I-D is needed or all we needed was to register a code point
>>> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
>>> happy to review.
>>>
>>> Chris P.
>>>
>>> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>>>
>>>> At the IETF 119 TLS session there was some interest in the mTLS Flag
>>>> I-D (https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/);
>>>> also, see previous list discussions at [0]. This message is to judge
>>>> consensus on whether there is sufficient support to adopt this I-D.  If you
>>>> support adoption and are willing to review and contribute text, please send
>>>> a message to the list.  If you do not support adoption of this I-D, please
>>>> send a message to the list and indicate why.  This call will close on 16
>>>> April 2024.
>>>>
>>>> Thanks,
>>>> Deirdre, Joe, and Sean
>>>>
>>>> [0]
>>>> https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
>>>> ___
>>>> 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 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] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

Adoption should not be required to register a code point [0], as the policy
is Specification Required.

I'm mildly negative on adopting this document. What is the reason we need
to spend WG time on this, rather than just having a code point assignment?

-Ekr

[0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
should clearly have
a policy which matches 8447 S 7, which is to say that an I-D is sufficient.


On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  wrote:

> I'd like to see this problem solved. There was some discussion about
> whether an I-D is needed or all we needed was to register a code point
> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
> happy to review.
>
> Chris P.
>
> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>
>> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
>> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
>> previous list discussions at [0]. This message is to judge consensus on
>> whether there is sufficient support to adopt this I-D.  If you support
>> adoption and are willing to review and contribute text, please send a
>> message to the list.  If you do not support adoption of this I-D, please
>> send a message to the list and indicate why.  This call will close on 16
>> April 2024.
>>
>> Thanks,
>> Deirdre, Joe, and Sean
>>
>> [0]
>> https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Eric Rescorla]

On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon  wrote:

> Encrypted dns transport works if you can trust the provider you are
> talking to. DNSSEC works even if you can’t. And if your provider is
> trustworthy, DNSSEC validation of results acquired through this tunnel
> should work. So it’s silly in this case to trust the tunnel—there’s no
> upside to doing so other than avoiding a few signature verifications.
>

I don't object to people doing DNSSEC validation of ECH records (though
AFAIK no major browser does so), but...

1. The resolver only gains a limited amount by forging the SVCB response
because the resolver already knows the domain name you are going to. This
does conceal (say) the ALPN, but that's usually less interesting than the
SNI.
2. If the authoritative domain is misconfigured, which is not unheard of,
then this can create resolution failures (this is true for A/, of
course). Probably not much of an issue for the big public recursives, but
can definitely be an issue if you are just talking to some locally-supplied
resolver.

-Ekr


> Op za 30 mrt 2024 om 14:02 schreef Rob Sayre 
>
>> On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren 
>> wrote:
>>
>>>
>>> An attacker who can prevent SVCB resolution can deny clients any
>>> associated security benefits.
>>>
>>>
>> Yes.
>>
>>
>>> A hostile recursive resolver can always deny service to SVCB queries,
>>> but network intermediaries can often prevent resolution as well, even when
>>> the client and recursive resolver validate DNSSEC and use a secure
>>> transport. These downgrade attacks can prevent a client from being aware
>>> that "ech" is configured which would result in the client sending the
>>> ClientHello in cleartext.
>>>
>>>
>> I think s/would/could/ here.
>>
>> I don't know if we want to write it, but doesn't using encrypted
>> transport DNS to an IP address avoid this problem? Like using 1.1.1.1 or
>> 8.8.8.8 etc. I know that raises centralization issues, but it does help
>> with this issue.
>>
>> thanks,
>> Rob
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Eric Rescorla]

Hi Ted,

Doesn't this section of RFC 9460 address this case and say what you are
recommending:

https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1

-Ekr



On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:

> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
> that you may or may not be doing DNSSEC validation. And you may or may not
> be /able/ to do DNSSEC validation if the infrastructure breaks it
> accidentally or deliberately.
>
> The document says: "The SVCB-optional client behavior specified in
> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
> if all SVCB options fail. This behavior is not suitable for ECH, because
> fallback would negate the privacy benefits of ECH."
>
> So it's saying that the default handling of SVCB is incorrect and would
> fail open, and overriding that behavior. Given that this is the case, that
> implies that it matters whether the data has been validated, but nowhere in
> the document, certainly not in Security Considerations, is any mention made
> of this issue. So that's what I'm pointing out.
>
> It is absolutely not the case in practice that all stub resolvers do
> validation. You are making a security decision about trust based on data
> the trustworthiness of which you've not discussed, in a situation where the
> implementor has meaningful choices to make with respect to validating that
> trustworthiness. So it's worth mentioning that if the policy is not to
> validate, this vulnerability exists.
>
> I'm a DNS guy, not a TLS guy, so I don't know the history of this work—I'm
> just making this observation about the document I was asked to review. The
> fact that (apparently) no DNSDIR review ever raised this issue about the
> other documents you mentioned is of no interest to me—I'm not reviewing
> those documents.Whether you take this advice is between you and the IESG.
> I'm not even claiming to be right—just pointing out the issue I see.
>
> On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:
>
>> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure)
>> or you can fail during ECH (unless you want to use non-ECH, which is not
>> ECH, and not part of this draft).
>>
>> It makes sense to me: one can reject a request unless the requirements
>> embedded in the SVCB are met (the server chooses those, which can include
>> many aspects of the request). I don't understand why one would insert
>> DNSSEC here. That seems to be the whole point--it works without it.
>>
>> thanks,
>> Rob
>>
>>
>> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>>
>>> I'm not telling you that you have to require DNSSEC. I'm saying the
>>> document is incomplete if you don't talk about how it relates to DNSSEC. I
>>> think EKR got the point, so maybe go with his approach?
>>>
>>> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>>>
 It's a policy choice, though, right? I think ekr hinted at this issue
 as well.

 It's that one might also view requests that reveal the SNI as insecure.
 If that's the case, DNSSEC doesn't help. There will certainly be a
 transition period where that will be impractical for many servers. I think
 these are separate problems, though.

 thanks,
 Rob


 On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:

> It looks like if you can't get the SCVB you're going to fail insecure,
> so being able to use DNSSEC to prevent that for signed domains seems
> worthwhile.
>
> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>
>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>>
>>> I don't think it's reasonable to specify the privacy properties of
>>> SVCB and
>>> /not/ talk about DNSSEC validation.
>>>
>>
>> Could you explain more about this part? I think DNSSEC doesn't add
>> much here, unless you want to accept non-ECH traffic. For example, many 
>> of
>> the test servers will bounce you to some other site if you don't send ECH
>> or screw it up in some way (speaking as someone who has screwed it up 
>> many
>> times...).
>>
>> I think there might be a DoS attack here, where someone messes with
>> the response, but they can also turn off the DNSSEC bit unless it's
>> DoT/DoH/DoQ etc. So, if using those, it's just the trustworthiness of the
>> DNS server itself, right? Sorry if I'm missing something.
>>
>> thanks,
>> Rob
>>
>> ___
> 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] -draft8447bis: rename Support Group Elliptic curve groups space

[Eric Rescorla]

On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly 
wrote:

> > KEMs are not "key agreement" algorithms as suggested by this draft
> name.  In a key agreement algorithm, both parties contribute to the shared
> secret.  With a KEM, only one party generates the the shared secreat value.
>
> This is not generally accurate with the KEM schemes under consideration
> for adoption by any standards bodies: in the -hybrid-design and
> -mlkem-key-agreement documents, the `Client` generates an ephemeral
> keypair, and the `Server` encapsulates to that keypair, but especially in
> ML-KEM which is under consideration in both documents, the KEM randomly
> sampled message `m` is sampled by the `Server` but the final
> `shared_secret` resulting from `Encaps` and `Decaps` is based on computing
> over the message `m`, the public key `PK` generated by the `Client`, as
> well as the randomized ciphertext `CT` generated by the `Server`. The
> encapsulated message `m` is not actually the `shared_secret` that is the
> input to the TLS 1.3  key schedule, even independent of the entire
> handshake transcript being included into the full key schedule as well.
>
> The naming of the document excluded 'key exchange' and 'key
> establishment', and went with 'key agreement', but that is a weakly held
> name,
>

I would probably rank order these as establishment > agreement > exchange,
but I'm not going to argue about these.

-Ekr


> On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  wrote:
>
>> Sean:
>>
>> I observe that ML-KEM is not a Elliptic curve group or a Finite Field
>> Diffie-Hellman group.  I really think we want to include sepport for KEMs.
>> but a separate range is needed.  I assume it will be carved out of the
>> Elliptic curve group range.
>>
>> KEMs are not "key agreement" algorithms as suggested by this draft name.
>> In a key agreement algorithm, both parties contribute to the shared
>> secret.  With a KEM, only one party generates the the shared secreat value.
>>
>> Russ
>>
>> > On Mar 28, 2024, at 10:52 AM, Sean Turner  wrote:
>> >
>> > 
>> >
>> > **WARNING: Potential bikeshed**
>> >
>> > -connolly-tls-mlkem-key-agreement has suggested that code points for
>> the NIST PQ be registered in the TLS Supported Groups IANA registry [1].
>> Currently [2], the registry is carved up into three blocks as follows:
>> >
>> > Range: 0-255, 512-65535
>> > Registration Procedures: Specification Required
>> > Note: Elliptic curve groups
>> >
>> > Range 256-511
>> > Registration Procedures: Specification Required
>> > Note: Finite Field Diffie-Hellman groups
>> >
>> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the
>> path for PQ KEM algorithms (and maybe regardless of whether this is the
>> path), we should really replace the “Elliptic curve groups” note in the
>> 0-255, 512-65535 range row with something else.  I am open to suggestions,
>> but would like to propose “unallocated”. I have submitted the following
>> issue:
>> > https://github.com/tlswg/rfc8447bis/issues/54
>> > and this PR:
>> > https://github.com/tlswg/rfc8447bis/pull/55
>> > to address this.
>> >
>> > spt
>> >
>> > [1]
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
>> >
>> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named
>> Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved
>> out the FFDH space.
>>
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Eric Rescorla]

On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker 
wrote:

> Reviewer: Ted Lemon
> Review result: Almost Ready
>
> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
>
> Section 4.1 advises disabling fallback, but does not talk about DNSSEC,
> which
> is surprising given that the draft proposes privacy properties for SVCB
> responses containing ECH data. I would think that it would make sense to
> say
> that the SVCB querier should attempt to validate the response, and then
> talk
> about what to do for bogus, insecure and valid positive and negative
> responses.
>
> For example, I would think that a /bogus/ response should be taken to mean
> that
> the SVCB record must be assumed to exist and should be treated the same as
> if
> the list of destinations were not reachable. An /insecure/ NXDOMAIN or
> NODATA
> response would not provide this assurance, and so what is currently
> described
> in the document makes sense for this case. A /valid/ NXDOMAIN would assure
> that
> no SVCB record existed, and hence ECH is not available.
>
> I don't think it's reasonable to specify the privacy properties of SVCB and
> /not/ talk about DNSSEC validation.
>

I could see that there might be an objection that if DNSSEC isn't working
> at a
> particular site because of a broken DNS resolver, this would prevent
> connecting
> to perfectly acceptable destinations simply because of general DNSSEC
> breakage,
> not a specific attack on this specific domain. The problem is that there's
> no
> way to distinguish this from an attack. So if this exception is allowed,
> the
> security considerations section should talk about what the risks are of
> allowing it. E.g. if we succeed in validing the root and com, but can't
> validate the zone containing the SVCB (or determine that it's not signed),
> that
> would be a clear indication of an attack, but if we can't validate the
> root, it
> could just be brokenness, and an attacker would do well to just prevent all
> validation so that we can't distinguish.


Thanks for your comments.

While I agree that SVCB being bogus deserves some consideration. I don't
think this
resolutions is *quite* correct. In general, TLS and HTTP don't take a
position
on what if any DNSSEC validation is to be done or what to do in response to
failures.

The new angle here is that there are two queries, and so it is possible for
the
A/ queries to produce a valid response but the SVCB to produce a bogus
one, which might be used by an attacker to disable ECH. What I would say
here
is that a bogus SVCB should be handled in the same way as if A/ were
bogus.
So if you would normally fail the resolution, you should do that, but if
you would
normally log and move on, then you should do that.

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

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 20, 2024 at 10:39 PM Raghu Saxena  wrote:

>
> On 3/15/24 00:02, Eric Rescorla wrote:
> >
> >
> > So, if I understand correctly, for my domain "abc.com
> > <http://abc.com>", I could
> > purposely choose to have my ECHConfig public_name be "google.com
> > <http://google.com>", and
> >
> >
> > As I said earlier, using "google.com <http://google.com>" would be
> > unwise because it
> > would allow Google to mount an attack where they terminated
> > the connection and replaced the ECHConfig. You should instead
> > use a name that is either unregistrable or that you control.
>
> Just so I understand correctly - the scope of the attack if they were to
> really intercept the TLS handshake and replace the ECHConfig, would
> allow them to "just" decrypt my ClientHelloInner, correct? Since
> ultimately the real origin I am connecting to (e.g. "mydomain.com") is
> not something they control, and so they can't present a valid cert for
> it and complete the full TLS connection (i.e. impersonate the true origin).
>

Correct.

-Ekr


At least this is what I understand from Section 6.1.7, specifically:
> "Note that authenticating a connection for the public name does not
> authenticate it for the origin. The TLS implementation MUST NOT report
> such connections as successful to the application."
>
> Regards,
>
> Raghu Saxena
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Sun, Mar 17, 2024 at 11:53 PM Karthikeyan Bhargavan <
karthikeyan.bharga...@inria.fr> wrote:

> Is there value in citing the security analysis for ECH as an informative
> reference?
>
> [image: 3548606.cover.jpg]
>
> A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello |
> Proceedings of the 2022 ACM SIGSAC Conference on Computer and
> Communications Security
> 
> dl.acm.org 
> 
>
>
> I expect this is quite late in the process for that:
>

Not at all, I think we just need to update the existing reference:

   [ECH-Analysis]
  "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
  Client Hello", November 2022.

Care to send a PR?


-Ekr


>
>
>
> On 12 Mar 2024, at 01:21, Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
> security
>
>
> ___
> 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] should we say anything about ECH in the face of fragmentation?

[Eric Rescorla]

On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> I think the outcome here is maybe most likely to do nothing but
> since the WGLC is ongoing I figured it best to bring it up in
> case others have better ideas.
>

Yes, I think the answer is "do nothing". TLS assumes that TCP correctly
delivers and sequences packets. There are a number of situations in
which the packet can be a size greater than 588 octets, and implementations
simply need to handle those correctly.

-Ekr


> I got a mail yesterday from someone who had played with the nginx
> "stream module" setup ECH-split-mode PoC stuff we've done and found
> a difference in how IP fragmentation affected that configuration,
> depending on whether or not ECH was enabled.
>
> The pcaps I've seen show fragmentation of the CH after 588 octets.
>
> In the ECH-using case, nginx aborts the connection as it sees a
> malformed outer CH. In the non-ECH case, nginx can decide how to
> forward the packets as it can decode into the partially rx'd CH
> and see the SNI (which is what's used to decide where to fwd the
> connection). I don't (yet) know what'd happen if fragmentation
> happened in the middle of the SNI in the non-ECH case. (I'd bet
> it'd not be good though:-)
>
> The reason for the difference is relatively obvious but I guess
> could be stated in the draft: an ECH split-mode front-end can't
> decrypt the ECH until it's seen the entire CH, due to the use of
> the ClientHelloOuterAAD as aad.
>
> I've not yet thought about whether it'd make sense to try to
> buffer up partially rx'd fragments to see if those eventually
> do turn out to be a nicely encoded outer CH - I suspect that
> may be more of a footgun than useful;-(
>
> I think all the exact same things would happen with our haproxy
> split-mode PoC, so this isn't an nginx specific issue.
>
> Cheers,
> S.
>
> ___
> 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] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Thu, Mar 14, 2024 at 5:53 AM Deirdre Connolly 
wrote:

> I would argue adding `ML-KEM` as a standalone NamedGroup is not more
> complex than adding ECDH groups, the hybrid part is the already complex
> part. To minimize complexity even more, one can 'just' do the X-Wing style
> of having a hybrid NamedGroup that doesn't know anything about the other
> available component NamedGroups, ie, no shared ephemeral ECDH or KEM
> keypairs: less complex, a little more compute.
>

I don't quite understand what complexity you are concerned with here in
terms of reuse.

As I understand it, S 3.2 of draft-hybrid permits the reuse of key shares
for a given group across hybrids, but does not require it. This means that:

1. You're free to generate your keys independently without reusing them.
2. Your behavior is the same even if the other side chooses to reuse keys.

The point being that implementations which want to save some compute can
absorb some complexity, but nobody is forced to. Am I misunderstanding?

-Ekr

I want there to be an option to negotiate ML-KEM alone, and turn off / not
> compile in the hybrid NamedGroups if I want to in my TLS 1.3 stack, and I
> think there will be a non-trivial user base for such an option very soon.
>
>
>
>
> On Thu, Mar 14, 2024 at 7:34 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> On 14/03/2024 01:41, Deirdre Connolly wrote:
>>
>> Oh and one more consideration: hybrid brings complexity, and presenting
>> the pure-PQ solutions and their strictly lesser complexity (at the tradeoff
>> of maybe taking more risk against newer schemes no matter how good we feel
>> about their fundamental cryptographic foundations) is worthwhile in my
>> opinion.
>>
>> On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly <
>> durumcrustu...@gmail.com> wrote:
>>
>>> [...] Shaking out all the negotiation decisions is desirable as well as
>>> 'drawing the rest of the owl' for the pure PQ option implied in the
>>> negotiation (are we going to copy the same ~1000 bytes for the PQ and
>>> hybrid name groups, when sharing an ephemeral KEM keypair?).
>>>
>> This is an argument that supporting PQ-only and PQ-hybrid simultaneously
>> will be more complex than just PQ-hybrids and require further changes at
>> the TLS layer.
>>
>> Given we've already paid the (minimal) complexity cost of hybrids and
>> switching to PQ-only seems strictly less secure, I'm really struggling to
>> see the motivation at this point in time. Once we're in a position to
>> remove the classical key exchanges from TLS entirely because we know
>> they're ineffective, switching to PQ-only might then have more benefit
>> since we could retire a lot of old code.
>>
>>
>>> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS,
>>> but a note that a non-trivial segment of users of standard TLS that have
>>> been traditionally compliant will not be in a few years, and they will come
>>> knocking anyway. This is trying to skate where the puck is going.
>>>
>>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
>>> agreement in the next ~6-9 years is a strong vote of confidence in any
>>> protocol doing this at all, so, TLS wouldn't be out on a limb to support
>>> this, basically.
>>>
>>> I don't have a strong opinion on whether this should be Recommended = Y.
>>>
>>> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie >>> 40uwe.nsa@dmarc.ietf.org> wrote:
>>>>
>>>>> Greetings Deirdre and TLS,
>>>>>
>>>>>
>>>>>
>>>>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>>>>> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
>>>>> and I have a few comments. First, though, I want to say thank you for
>>>>> writing this draft. I'll echo some of what has already been voiced on this
>>>>> thread and say that, while some plan to use composite key establishment, 
>>>>> it
>>>>> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
>>>>> another option. Other WGs (lamps and ipsecme) have already begun to 
>>>>> specify
>>>>> the use of standalone FIPS 203, 204, and 205 in various protocols. With
>>>>> respect to this draft, there is certainly interest from National Security
>>>>> System

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena  wrote:

>
> On 3/14/24 00:45, Eric Rescorla wrote:
> > There are two questions here:
> >
> > 1. What the specification says
> > 2. What implementations choose to do within the envelope of that
> > specification.
> >
> > The specification needs to prescribe a set of behaviors that promote
> > interoperability, which means that whatever it tells the client to do
> > must be compatible with what it tells servers to do. Presently, the
> > specification tells clients to put whatever is in
> > ECHConfig.public_name in ClientHelloOuter.sni (S 6.1) and tells the
> > server that it may check and reject it otherwise (S 7.1).
>
> So, if I understand correctly, for my domain "abc.com", I could
> purposely choose to have my ECHConfig public_name be "google.com", and
>

As I said earlier, using "google.com" would be unwise because it
would allow Google to mount an attack where they terminated
the connection and replaced the ECHConfig. You should instead
use a name that is either unregistrable or that you control.


configure my server to handle it (or ignore the SNI in outer client
> hello altogether), and a client SHOULD NOT try and cancel the ECH
> attempt on seeing that the public_name in ECHConfig does not match the
> host the user is attempting to connect to?
>

As long as your server completes ECH, then it doesn't matter that
the certificate it presents is not valid for the public_name. However,
if you are unable to complete ECH (e.g., you have forgotten the
key and want to do the recovery mechanism), then this will
cause an error on the client.

-Ekr


> I guess this makes sense, since in the Cloudflare case, every ECHConfig
> advertises public_name as "cloudflare-ech.com", and the user is
> obviously connecting to a different website. In this case I guess it
> isn't as bad, since as a server operator I _could_ choose to just
> piggyback on the public_name of some popular CDN, even though I am not
> using it, to "hide" my real SNI / domain. I think this is a feasible
> workaround.
>
> Regards,
>
> Raghu Saxena
>
> ___
> 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] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 13, 2024 at 4:10 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>
>
>
> I don't think there is any particular reason to include PQC signatures in
> the same draft as PQ key establishment. In TLS 1.3, key establishment and
> signature are orthogonal concepts, and it will be easier to review if they
> are kept in separate documents.
>
>
>
> On the one hand – you’re correct. On the other hand, though, considering
> implicitly-authenticated protocols, such as MQV, HMQV etc…?
>
*Yes I’m aware that they don’t use explicit signatures, except to validate
> certificates.*
>

TLS 1.3 does not support MQV or HMQV.

-Ekr


>
>
> *From:* TLS  *On Behalf Of *Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
>
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
>
>
> Cheers,
>
> Deirdre
>
> ___
> 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] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie  wrote:

> Greetings Deirdre and TLS,
>
>
>
> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
> and I have a few comments. First, though, I want to say thank you for
> writing this draft. I'll echo some of what has already been voiced on this
> thread and say that, while some plan to use composite key establishment, it
> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
> another option. Other WGs (lamps and ipsecme) have already begun to specify
> the use of standalone FIPS 203, 204, and 205 in various protocols. With
> respect to this draft, there is certainly interest from National Security
> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
> security).
>

I wanted to address this CNSA 2.0 point, as I've now seen it brought up a
couple of times.

The IETF, together with the IRTF, needs to make an independent judgement on
whether using PQ-only algorithms is advisable, and if we do not think so,
then we should not standardize them, regardless of what CNSA 2.0 requires.
The supported groups registry policies are designed explicitly to allow
people to register non Standards Track algorithms, so nothing precludes the
creation of an ML-KEM only code point if some vendors find that necessary,
without the IETF standardizing them or marking them as Recommended=Y.
-Ekr




>
> A few specific comments:
>
>
>
> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
> would suggest that the second sentence ("Having a fully post-quantum...")
> is not needed, i.e. that there need not be a justification for why it is
> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
> appropriate to contextualize the specification of ML-KEM w.r.t the advent
> of a CRQC, though I also don't think that is necessary. As an example, we
> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>
>
>
> 2. Section 3 (Construction on github) currently reads, "We align with
> [hybrid] except that instead of joining ECDH options with a KEM, we just
> have the KEM as a NamedGroup." I think it is a more useful framing to base
> this specification (for the use of a standalone algorithm) off of RFC 8446
> instead of the draft spec for a hybrid solution. I understand wanting to
> align the approach with the approach taken for the hybrid solution, but I
> don't think that fact needs to be explicitly documented in this draft. When
> this draft is standardized, I think it's important that it is able to be
> read, understood, and implemented without needing to refer to the hybrid
> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
> sent in the supported_groups extension."
>
>
>
> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
> phrase "groups" to refer to key exchange algorithms -- for example, the
> supported_groups extension -- since all key exchange algorithms in TLS 1.3
> are Diffie-Hellman-based.  As a result, some parts of this document will
> refer to data structures or messages with the term "group" in them despite
> using a key exchange algorithm that is not Diffie-Hellman-based nor a
> group."
>
> This seems okay, but on the IANA registry for TLS Supported Groups, it
> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
> to accommodate QR KEMs.
>
>
>
> 4. In the Discussion section (on github), does the portion on failures
> need to contain more information about how a failure should be handled in
> TLS? Should a decrypt_error alert be sent?
>
>
>
> 5. In Section 4 (or Security Considerations on github), this may be a
> silly question, but is the definition of "commits" well-understood (in the
> first sentence on datatracker; in the first sentence of Binding properties
> on github)? It is not used in RFC 8446 so it might be worth explaining the
> meaning or using different phrasing in this sentence.
>
>
>
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> Thanks in advance!
>
>
>
> Rebecca
>
>
>
> Rebecca Guthrie
>
> she/her
>
> Center for Cybersecurity Standards (CCSS)
>
> Cybersecurity Collaboration Center (CCC)
>
> National Security Agency (NSA)
>
>
>
> *From:* TLS  *On Behalf Of * Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>

I don't think there is any particular reason to include PQC signatures in
the same draft as PQ key establishment. In TLS 1.3, key establishment and
signature are orthogonal concepts, and it will be easier to review if they
are kept in separate documents.

-Ekr


>
>
>
> *From:* TLS  *On Behalf Of *Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
>
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
>
>
> Cheers,
>
> Deirdre
> ___
> 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] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 9:20 AM Amir Omidi  wrote:

> > I don't think it's realistic for a generic client (e.g., a standard
> browser) to omit or falsify this field.
>
> Why not? From my understanding the issue that happens in this situation is
> that the website becomes less reliable for these TLS clients?
>
> If so, let that be a problem for the client to deal with. All this change
> would do is something in security considerations along the lines of "to
> make this protocol more censorship resistant, a TLS client MAY choose to
> omit, or randomly generate the contents of `public_name`. A TLS Server
> SHOULD handle these situations gracefully, and not actively reject the
> client".
>

But this will actually cause hard failures for any server which shares an
IP.


I do not like the idea of saying "some website can choose to do this". In
> practice, very few websites will go down that route.
>

Yes, because it's not of benefit for websites which share an IP.



> Are there any concerns if this approach is used?
>

There are two questions here:

1. What the specification says
2. What implementations choose to do within the envelope of that
specification.

The specification needs to prescribe a set of behaviors that promote
interoperability, which means that whatever it tells the client to do must
be compatible with what it tells servers to do. Presently, the
specification tells clients to put whatever is in ECHConfig.public_name in
ClientHelloOuter.sni (S 6.1) and tells the server that it may check and
reject it otherwise (S 7.1). We extensively debated whether to forbid
checking in PR #575 and concluded that we should do so. The primary
arguments were the same ones being offered here balanced against the
ecosystem benefits of encouraging the client to correctly populate
ClientHelloOuter.sni to enable the  recovery mechanism. The WG could of
course revisit that decision.

With that said, even if the specification explicitly allowed clients to
omit/falsify ClientHelloOuter.sni, I don't believe that generic clients
(e.g., the kind of Web browsers that most people use) would choose to do
so. The reason is that, as noted above, it would break the recovery
mechanism, and that's more important than the modest increment in
concealing the public_name of servers on non-shared IPs. One might imagine
that some special purpose clients would choose to do so, but that's not the
case I'm talking about.

-Ekr


> On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 8:49 AM A A  wrote:
>>
>>> I think we should change outer SNI randomly and periodicity (e.g 1
>>> hours), if it change fast enough, censor will need to pay a price to block
>>> it,
>>>
>>
>> This won't work because the public_name is part of the recovery mechanism
>> for misconfiguration, which means that the server needs to have a valid
>> certificate with that identity.
>>
>> -Ekr
>>
>>
>>>
>>> 13.03.2024, 23:40, "Amir Omidi" :
>>>
>>> I'd like to understand how the behavior of the latest draft will be
>>> under an adversarial condition.
>>>
>>> One of the things that really excited me about ESNI back in the day was
>>> effectively making it near impossible for countries, like my home country
>>> Iran, from being able to effectively censor the web. AFAIK Iran's main
>>> censorship mechanism revolves around looking for ClientHello's and then
>>> sending a TCP reset when that SNI matches a censored domain.
>>>
>>> I'm wondering, are we losing that ability from ESNI with this plain text
>>> field? Maybe there can be an understanding in the RFC that the client may
>>> omit, or falsify this plaintext field for a bit of extra adversarial
>>> security in these circumstances?
>>>
>>> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
>>> wrote:
>>>
>>> On 3/13/24 14:51, Watson Ladd wrote:
>>>
>>> > I'm not sure what problem you want us to solve here. In the case of
>>> > server offering a single domain, an attacker can determine that
>>> > connections to that domain go to the server and cheaply block based on
>>> > IP. As a result the threat model is one of distinguishing between
>>> > connections to two different inner names.
>>>
>>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>>> at a higher level, for the exact reason that IPs can change

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 8:49 AM A A  wrote:

> I think we should change outer SNI randomly and periodicity (e.g 1 hours),
> if it change fast enough, censor will need to pay a price to block it,
>

This won't work because the public_name is part of the recovery mechanism
for misconfiguration, which means that the server needs to have a valid
certificate with that identity.

-Ekr


>
> 13.03.2024, 23:40, "Amir Omidi" :
>
> I'd like to understand how the behavior of the latest draft will be under
> an adversarial condition.
>
> One of the things that really excited me about ESNI back in the day was
> effectively making it near impossible for countries, like my home country
> Iran, from being able to effectively censor the web. AFAIK Iran's main
> censorship mechanism revolves around looking for ClientHello's and then
> sending a TCP reset when that SNI matches a censored domain.
>
> I'm wondering, are we losing that ability from ESNI with this plain text
> field? Maybe there can be an understanding in the RFC that the client may
> omit, or falsify this plaintext field for a bit of extra adversarial
> security in these circumstances?
>
> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>
>
>
> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
> wrote:
>
> On 3/13/24 14:51, Watson Ladd wrote:
>
> > I'm not sure what problem you want us to solve here. In the case of
> > server offering a single domain, an attacker can determine that
> > connections to that domain go to the server and cheaply block based on
> > IP. As a result the threat model is one of distinguishing between
> > connections to two different inner names.
>
> An IP can be cheaply recycled as well, for instance restarting a VPS on
> a cloud provider. Furthermore, IP based blocking may even be discouraged
> at a higher level, for the exact reason that IPs can change pretty
> easily. As an operator, I might be able to migrate my hosting to a new
> server provider (and hence IP) trivially, but informing my users of a
> domain change is much harder.
>
>
> Yes, but the attacker can easily learn these IPs merely by querying
> the DNS. Moreover, they can learn the associated domains by sending
> a CH with no SNI at all and seeing what's in the certificate.
>
>
> > DNS does not propagate atomically with webserver configuration
> > changes. It's thus necessary to deal with mismatches.
> While this is true, if there is a configuration mismatch (and hence ECH
> cannot work), why is the decision made for the server to transparently
> "downgrade" it to non-ECH, instead of sending some kind of alert that
> signifies the client to retry without ECH?
>
>
> Three reasons:
>
> 1. Such an alert would be insecure because an attacker could forge it,
> thus causing the client to send ECH in the clear.
>
> 2. It allows the server to be completely ECH unaware rather than needing
> to special case an ECH alert.
>
> 3. It allows the server to securely provide a new ECHConfig.
>
> -Ekr
>
>
>
> Regards,
>
> Raghu Saxena
>
> ___
> 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 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] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 8:40 AM Amir Omidi  wrote:

> I'd like to understand how the behavior of the latest draft will be under
> an adversarial condition.
>
> One of the things that really excited me about ESNI back in the day was
> effectively making it near impossible for countries, like my home country
> Iran, from being able to effectively censor the web. AFAIK Iran's main
> censorship mechanism revolves around looking for ClientHello's and then
> sending a TCP reset when that SNI matches a censored domain.
>
> I'm wondering, are we losing that ability from ESNI with this plain text
> field? Maybe there can be an understanding in the RFC that the client may
> omit, or falsify this plaintext field for a bit of extra adversarial
> security in these circumstances?
>

I don't think it's realistic for a generic client (e.g., a standard
browser) to omit or falsify this field.

The public_name is necessary to make the recovery mechanism defined in S
6.1.6. It may be the case that there are servers that only have one
identity --  though as both Watson and I noted, ECH doesn't provide much
value in those cases -- and not care about recovery, but there is no way
for the client to know that. With that said, I don't think that anything
prevents a server from placing a non-registrable value (e.g.,
`esni.invalid`) in `public_name`, which has roughly the same impact if
people converge on a small number of such names. [0]

-Ekr

[0] The value must be non-registrable -- or at least controlled by the
server -- otherwise an attacker might register it and obtain a valid
certificate, thus initiating the 6.1.6 recovery mechanism.


> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
>> wrote:
>>
>>> On 3/13/24 14:51, Watson Ladd wrote:
>>>
>>> > I'm not sure what problem you want us to solve here. In the case of
>>> > server offering a single domain, an attacker can determine that
>>> > connections to that domain go to the server and cheaply block based on
>>> > IP. As a result the threat model is one of distinguishing between
>>> > connections to two different inner names.
>>>
>>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>>> at a higher level, for the exact reason that IPs can change pretty
>>> easily. As an operator, I might be able to migrate my hosting to a new
>>> server provider (and hence IP) trivially, but informing my users of a
>>> domain change is much harder.
>>>
>>
>> Yes, but the attacker can easily learn these IPs merely by querying
>> the DNS. Moreover, they can learn the associated domains by sending
>> a CH with no SNI at all and seeing what's in the certificate.
>>
>>
>> > DNS does not propagate atomically with webserver configuration
>>> > changes. It's thus necessary to deal with mismatches.
>>> While this is true, if there is a configuration mismatch (and hence ECH
>>> cannot work), why is the decision made for the server to transparently
>>> "downgrade" it to non-ECH, instead of sending some kind of alert that
>>> signifies the client to retry without ECH?
>>>
>>
>> Three reasons:
>>
>> 1. Such an alert would be insecure because an attacker could forge it,
>> thus causing the client to send ECH in the clear.
>>
>> 2. It allows the server to be completely ECH unaware rather than needing
>> to special case an ECH alert.
>>
>> 3. It allows the server to securely provide a new ECHConfig.
>>
>> -Ekr
>>
>>
>>
>>> Regards,
>>>
>>> Raghu Saxena
>>>
>>> ___
>>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena  wrote:

> On 3/13/24 14:51, Watson Ladd wrote:
>
> > I'm not sure what problem you want us to solve here. In the case of
> > server offering a single domain, an attacker can determine that
> > connections to that domain go to the server and cheaply block based on
> > IP. As a result the threat model is one of distinguishing between
> > connections to two different inner names.
>
> An IP can be cheaply recycled as well, for instance restarting a VPS on
> a cloud provider. Furthermore, IP based blocking may even be discouraged
> at a higher level, for the exact reason that IPs can change pretty
> easily. As an operator, I might be able to migrate my hosting to a new
> server provider (and hence IP) trivially, but informing my users of a
> domain change is much harder.
>

Yes, but the attacker can easily learn these IPs merely by querying
the DNS. Moreover, they can learn the associated domains by sending
a CH with no SNI at all and seeing what's in the certificate.


> DNS does not propagate atomically with webserver configuration
> > changes. It's thus necessary to deal with mismatches.
> While this is true, if there is a configuration mismatch (and hence ECH
> cannot work), why is the decision made for the server to transparently
> "downgrade" it to non-ECH, instead of sending some kind of alert that
> signifies the client to retry without ECH?
>

Three reasons:

1. Such an alert would be insecure because an attacker could forge it,
thus causing the client to send ECH in the clear.

2. It allows the server to be completely ECH unaware rather than needing
to special case an ECH alert.

3. It allows the server to securely provide a new ECHConfig.

-Ekr



> Regards,
>
> Raghu Saxena
>
> ___
> 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] Working Group Last Call for SSLKEYLOG File

[Eric Rescorla]

On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell 
wrote:

>
> I'll argue just a little more then shut up...
>
> On 12/03/2024 22:55, Martin Thomson wrote:
> >
> >> Sorry also for a late suggestion, but how'd we feel about adding
> >> some text like this to 1.1?
> >>
> >> "An implementation, esp. a server, emitting a log file such as this
> >> in a production environment where the TLS clients are unaware that
> >> logging is happening, could fall afoul of regulatory requirements
> >> to protect client data using state-of-the-art mechanisms."
>
> > I agree with Ekr.  That risk is not appreciably changed by the
> > existence of a definition for a file format.
> I totally do consider our documenting this format increases
> the risk that production systems have such logging enabled,
> despite our saying "MUST NOT." So if there's a way to further
> disincentivise doing that, by even obliquely referring to
> potential negative consequences of doing so, then I'd be for
> doing that.


Aside from this particular case, I don't think technical specifications
should "obliquely" refer to things. Technical specifications should be
clear.

-Ekr

Hence my suggestion.
>
> S.
> ___
> 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] Working Group Last Call for SSLKEYLOG File

[Eric Rescorla]

On Tue, Mar 12, 2024 at 3:45 PM Stephen Farrell 
wrote:

>
>
> On 12/03/2024 22:06, Eric Rescorla wrote:
> > I don't think we should make statements about regulatory requirements
> > in this kind of specification. That's not our lane.
>
> I'd weakly disagree about making statements such as suggested,
> while agreeing with "not out lane." I don't think the text I
> suggested crosses that line, but it's fine if others disagree
> of course.
>

> I'd also be ok if we only stated that emitting these logs in
> production systems means not deploying state of the art security
> and letting the rest of the world connect the dots.
>

Lots of things don't constitute not deploying state of the art security,
including, arguable, not using PQ algorithms.

I think we should be very clear about the technical consequences of
implementing this specification in the Security Considerations (which I
think they are) but that either this statement or the one you previously
proposed is not helpful.
-Ekr


>
> Cheers,
> S.
>
> PS: to be clear, I'm not objecting to progression if my
> suggestion isn't adopted.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Eric Rescorla]

On Tue, Mar 12, 2024 at 2:40 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 12/03/2024 14:57, Sean Turner wrote:
> > This is the working group last call for the SSLKEYLOGFILE Format for
> > TLS Internet-Draft [1]. Please indicate if you think the I-D is ready
> > to progress to the IESG and send any comments to the list by 31 March
> > 2024.
>
> This is not my fav thing, but I guess I've also benefited from
> it during development, so with a bit of nose-holding, I suppose
> it's ready. (Apologies to Martin for the grudging acceptance of
> his worthy effort;-)
>
> Sorry also for a late suggestion, but how'd we feel about adding
> some text like this to 1.1?
>
> "An implementation, esp. a server, emitting a log file such
>  as this in a production environment where the TLS clients are
>  unaware that logging is happening, could fall afoul of regulatory
>  requirements to protect client data using state-of-the-art
>  mechanisms."
>

I don't think we should make statements about regulatory requirements
in this kind of specification. That's not our lane.

-Ekr


> Another thought occurred to me that I don't recall being mentioned
> before: given we're defining a mime type, that suggests sending
> these files by mail or in an HTTP response. Doing that could
> be leaky, esp. if only one side of the TLS connection reflected in
> the file were aware that logging was being done and if the other
> side then sends the file via unencrypted email. I guess one
> could also envisage a weird case where a server did this and
> also located the log file inside the DocRoot enabling some
> clients to see the secrets of some other clients (or their own).
> I'm not sure if either scenario, or any similar scenario justifies
> an additional warning to be careful where you send files using
> that mime type? If it seems worth including, grand. If not, that's
> ok.
>
> Cheers,
> S.
>
> ___
> 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] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Thu, Mar 7, 2024 at 1:47 AM Dennis Jackson  wrote:

> On 07/03/2024 03:57, Bas Westerbaan wrote:
>
> We think it's worth it now, but of course we're not going to keep hybrids
> around when the CRQC arrives.
>
> Sure, but for now we gain substantial security margin* against
> implementation mistakes, advances in cryptography, etc.
>
> On the perf/cost side, we're already making a large number of sub-optimal
> choices (use of SHA-3, use of Kyber in TLS rather than a CPA scheme,
> picking 768 over 512, etc), we can easily 'pay' for X25519 if you really
> wanted. I think if handshake cycles really mattered then we'd have shown
> RSA the door much more quickly [1].
>
> Best,
> Dennis
>
> * As in, actual security from combination of independent systems, not the
> mostly useless kind from using over-size primitives.
>
In a world where there is a CRQC, there are two distinct costs to
continuing to support hybrids:

1. The computational cost of actually doing X25519 (or whatever)
2. The software complexity cost of the code to do the hybrid and to
negotiate it.

>From the perspective of an implementation the computational cost scales
with the
number of handshakes it has to do with the hybrid rather than pure ML-KEM.
The complexity cost, however, is constant up to the point where you can
remove it
entirely. Because of the highly centralized structure of the TLS browser
and server
ecosystem, these timelines can be very different: it's relatively fast to
get to high
levels of deployment so that most handshakes are "new", but can be quite
slow
to eliminate the last "old-only" peers.

So, the question I have is whether having a code point for pure ML-KEM now
advances the project of deprecating hybrids at the point where the X25519
part
isn't doing anything meaningful (again, assuming that point eventually
comes).
My sense is that it largely does so if fielded implementations are willing
to do
pure-ML-KEM, because, as above, it's that quantity that dominates the
decision
of whether you can remove the hybrid code entirely. Personally, I'd still
be quite
uncomfortable with allowing pure ML-KEM negotiation in a major product. If
others
feel the same way, I'm not quite sure what it gets us, other than saving us
the
fairly small amount of specification effort of doing the pure version.

It's of course worth noting that a CRQC might be very far in the future and
we
might get better PQ algorithms by that point, in which case we'd never
deploy
pure ML-KEM.

-Ekr


> [1] https://blog.cloudflare.com/how-expensive-is-crypto-anyway
>
>
> Best,
>
>  Bas
>
> On Thu, Mar 7, 2024 at 1:56 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> I'd like to understand the argument for why a transition back to single
>> schemes would be desirable.
>>
>> Having hybrids be the new standard seems to be a nice win for security
>> and pretty much negligible costs in terms of performance, complexity and
>> bandwidth (over single PQ schemes).
>>
>> On 07/03/2024 00:31, Watson Ladd wrote:
>> > On Wed, Mar 6, 2024, 10:48 AM Rob Sayre  wrote:
>> >> On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla  wrote:
>> >>>
>> >>>
>> >>> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly <
>> durumcrustu...@gmail.com> wrote:
>> >>>>> Can you say what the motivation is for being "fully post-quantum"
>> rather than hybrid?
>> >>>> Sure: in the broad scope, hybrid introduces complexity in the
>> short-term that we would like to move off of in the long-term - for TLS 1.3
>> key agreement this is not the worst thing in the world and we can afford
>> it, but hybrid is by design a hedge, and theoretically a temporary one.
>> >>>
>> >>> My view is that this is likely to be the *very* long term.
>> >>
>> >> Also, the ship has sailed somewhat, right? Like Google Chrome,
>> Cloudflare, and Apple iMessage already have hybrids shipping (I'm sure
>> there many more, those are just really popular examples). The installed
>> base is already very big, and it will be around for a while, whatever the
>> IETF decides to do.
>> > People can drop support in browsers fairly easily especially for an
>> > experimental codepoint. It's essential that this happen: if everything
>> > we (in the communal sense) tried had to be supported in perpetuity, it
>> > would be a recipe for trying nothing.
>> >
>> >> thanks,
>> >> Rob
>> >>
>> >> ___
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly 
wrote:

> > Can you say what the motivation is for being "fully post-quantum" rather
> than hybrid?
>
> Sure: in the broad scope, hybrid introduces complexity in the short-term
> that we would like to move off of in the long-term - for TLS 1.3 key
> agreement this is not the worst thing in the world and we can afford it,
> but hybrid is by design a hedge, and theoretically a temporary one.
>

My view is that this is likely to be the *very* long term.

I'm open to being persuaded, but at the moment, I don't think there is
anywhere near enough confidence in any of the PQ algorithms to confidently
use it standalone, which means we're going to see a lot of hybrid
deployment sooner rather than later. This also means that we're going to
have a long tail of clients and servers which only do hybrid and not
PQ-only, so that complexity is baked in for quite some time to come.


> In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines
> <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>
> currently are a big 'maybe' at best for 'hybrid solutions', and the
> timetables for compliant browsers, servers, and services are to exclusively
> use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
> demand for pure ML-KEM key agreement, not hybrid (with no questions that
> come along with it of whether it's actually allowed or not).
>

I'm honestly not moved by this very much. IETF should form its own opinion
about the security of algorithms, not just take whatever opinions are
handed down from NIST. If that means that IETF doesn't standardize what
NIST wants, then NIST is free to register its own codepoints and try to
persuade implementors to take them.

So I think the question here should be focused on "what level of confidence
would IETF need to specify ML-KEM standalone at Proposed Standard with
Recommended=Y".

-Ekr


> Relatedly, the currently adopted -hybrid-design
> <https://dstebila.github.io/draft-ietf-tls-hybrid-design/draft-ietf-tls-hybrid-design.html>
> outlines several combinations of ECDH and KEM, and allows computing the
> ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM
> share, but there is no equivalent for just using a KEM on its own, and
> computing its shared secret once and advertising it as both standalone and
> in a hybrid share. So I think defining these standalone ML-KEM
> `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design.
>
> On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla  wrote:
>
>> Deirdre, thanks for submitting this. Can you say what the motivation is
>> for being "fully post-quantum" rather than hybrid?
>>
>> Thanks,
>> -Ekr
>>
>>
>>
>> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
>> wrote:
>>
>>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>>> and have a more fleshed out
>>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version to
>>> be uploaded when datatracker opens. It is a straightforward new
>>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>>> very similar style to -hybrid-design
>>> <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>.
>>>
>>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>>> compatible) ready to go when users are ready to use them.
>>>
>>> Cheers,
>>> Deirdre
>>> ___
>>> 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] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

Deirdre, thanks for submitting this. Can you say what the motivation is for
being "fully post-quantum" rather than hybrid?

Thanks,
-Ekr



On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
> Cheers,
> Deirdre
> ___
> 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] Status of draft-ietf-tls-rfc8446bis

[Eric Rescorla]

On Sat, Feb 17, 2024 at 11:16 PM Muhammad Usama Sardar <
muhammad_usama.sar...@tu-dresden.de> wrote:

> On 17.02.24 17:31, Eric Rescorla wrote:
>
> > As I understand it, you think that the changes we made in PR#185 may
> > have been unnecessary
> > and that it would be good to have more analysis of that. Is that
> > roughly correct?
>
> Yes, except that the relevant PR is #875. Since there is silence for
> last 2 months on the thread that I started, I assume nobody has any
> further insights on the matter, and thus it will be good to have more
> analysis.
>

I wouldn't object to more analysis, but given the relatively narrow remit
of this
document and that changing the key schedule would obviously create wire
format incompatibilities, I wouldn't want to do that absent some evidence
that the change was insecure as opposed to unnecessary.

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

Re: [TLS] Status of draft-ietf-tls-esni

[Eric Rescorla]

On Sat, Feb 17, 2024 at 11:09 AM Stephen Farrell 
wrote:

>
>
> On 17/02/2024 18:56, Eric Rescorla wrote:
> > I should be able to spin a WGLC-ready version of ECH before the
> > draft deadline.
>
> Good stuff, thanks. I'll plan to review the proposed
> changes with a strong bias for not asking for more:-)


Thanks! If you have limited time, I think spend it on 604. The rest is
hopefully just editorial-ish.

-Ekr


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

[TLS] Status of draft-ietf-tls-esni

[Eric Rescorla]

Hi folks,

I wanted to provide an update on draft-ietf-tls-esni. I went through
all existing PRs and issues as well as some of the recent list
discussion. This message provides a summary of the status:

PRs
* 594: A first proposal to fix the no-sni section [Arnaud Taddei]
  I think this is fine and will merge on 2/24 unless people object.

* 602: More explanatory text [EKR]
  This is a pretty substantial rewrite of the overview section
  to address some of the clarity issues raised by Arnaud Taddei.
  This is editorial, but needs review.

* 603: Clarify that you can fall back by providing no ECH in EE [EKR]
  This addresses a point made by Elardus Erasmus about what indicated
  you're disabling ECH. Hopefully this is uncontroversial.

Arnaud also provided two editorial PRs with clarifications
(587 and 588). I believe that these are addressed by 602.



ISSUES
* 866: Server retry flow, section 7.1 [Robert Sayre]
  I'm not seeing support for a change here, so I propose to
  close unless someone provides a PR that receives some
  support.

* 591: Can we clarify the Misconfiguration section? [Arnaud Taddei]
  This is addressed in PR #602, so I propose to close it once that
  lands.


Finally, Erlardus Erasmus raised some issues around limiting
retries (
https://mailarchive.ietf.org/arch/msg/tls/bvvWbtxJAiMfilfy32EvdaCszQ4/).
I have filed an issue with some thoughts at:

  https://github.com/tlswg/draft-ietf-tls-esni/issues/604

I think this needs some discussion before we have a PR.


Assuming that there are no strong objections to the resolutions
of the PRs and issues above and we can get consensus on Issue 604,
I should be able to spin a WGLC-ready version of ECH before the
draft deadline.

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

Re: [TLS] Input on ECH specification

[Eric Rescorla]

On Wed, Feb 7, 2024 at 2:06 PM Elardus Erasmus  wrote:

> Hi,
>
> I figured it would be better to send an email, rather than proposing and
> discussing this on a PR (proposed edits/diffs are at the bottom of this
> email).
>
> We have two suggestions regarding the specification text (
> https://datatracker.ietf.org/doc/draft-ietf-tls-esni/):
>
> *Suggestion 1*
>
> Make it clear that if an ECH extension is absent from the server_hello, it
> qualifies as an ECH disabling signal. The text earlier in the section
> already requires that “both authentication and the handshake complete
> successfully” in the initial ECH-enabled connection, for ECH to be regarded
> as disabled. The same (ECH disabling due to absent ECH ext from server) can
> be deducted by reading a few paragraphs, but even then, it is not clear.
> This makes it much clearer.
>
> In Section 6.1.6, change:
>
> If none of the values provided in "retry_configs" contains a supported
> version,
> or an earlier TLS version was negotiated, the client can regard ECH as
> securely
> disabled by the server, and it SHOULD retry the handshake with a new
> transport
> connection and ECH disabled.
>
> To:
>
> If none of the values provided in "retry_configs" contains a supported
> version,
> or an earlier TLS version was negotiated, *or the server did not supply
> an*
> *"encrypted_client_hello" extension in its EncryptedExtensions message,*
> the
> client can regard ECH as securely disabled by the server. It SHOULD retry
> the handshake with a new transport connection and ECH disabled.
>

I agree with this. I have created PR #603 to address this:
https://github.com/tlswg/draft-ietf-tls-esni/pull/603





> *Suggestion 2*
>
> Section 6.1.6 also mentions that:
>
> Clients SHOULD implement a limit on retries caused by receipt of
> "retry_configs"
> or servers which do not acknowledge the "encrypted_client_hello" extension.
>
> The text does not differentiate between *retry types* for the purpose of
> limiting the connections. I.e., if the ECH config was replaced, then it is
> an *ECH-enabled* retry (with new keys). But if ECH was disabled, then it
> is an * ECH-disabled* retry. Limiting the connections makes sense for
> *ECH-enabled* retries due to config replacement, since the connections
> seem not be successful in any case and thus the extra load is not
> necessary. But limiting it for *ECH-disabled* connections could mean that
> connections may start failing abruptly, depending on the aggressiveness of
> the limit on the client. As long as ECH-disabled connections succeed, they
> should not be limited so that connectivity does not suffer unnecessarily.
>

I think I agree with you that we shouldn't limit




> It would probably even be good/necessary to implement a *holdoff* on the
> client in the *ECH-disabled* case. I.e., not making an ECH-enabled
> connection to an SNI that resulted in ECH disabling for some duration of
> time. Some scenarios where this would be desirable:
>
>- The ECH version steps. This will lead to ECH-disabled retries.
>During DNS propagation time, the number of connections to client-facing
>servers of ECH enabled sites will double (say a large CDN activates a
>version step of all its sites all at once). Clients that limit retries
>could experience connectivity issues, but clients that implement a holdoff
>would mitigate the connection doubling problem in such a scenario.
>- A server disables ECH temporarily or serves TLS 1.2. Again, ECH will
>be securely disabled, and a connectivity loss may occur (retry limit). A
>doubling in connections will be experienced until DNS propagation is
>finished - or indefinitely in case of a config issue (e.g. server
>administrator does not remove ECH config from DNS).
>- Section 8.2 talks about middleboxes acting as TLS-terminating
>proxies. All connections going through such proxies will result in ECH
>being disabled (due to the ECH extension being absent from the
>server_hello). Also leading to a possible connectivity loss, or at the very
>least a permanent doubling in connections.
>
> The “connection doubling” in the scenarios above increases connection
> establishment latency and adds load to the client, server, middlebox, and
> other stateful network devices, and can be mitigated by a temporary holdoff
> on ECH-enabled connections on the client.
>
> The proposal is therefore to change Section 6.1.6 from:
>
> If none of the values provided in "retry_configs" contains a supported
> version,
> or an earlier TLS version was negotiated, the client can regard ECH as
> securely
> disabled by the server, and it SHOULD retry the handshake with a new
> transport
> connection and ECH disabled.
>
>
>
> Clients SHOULD implement a limit on retries caused by receipt of
> "retry_configs"
> or servers which do not acknowledge the "encrypted_client_hello"
> extension. If
> the client does not retry in either scenario, it MUST report an error to
> the
> 

Re: [TLS] Status of draft-ietf-tls-rfc8446bis

[Eric Rescorla]

I don't quite understand what it is you're asking for here.

As I understand it, you think that the changes we made in PR#185 may have
been unnecessary
and that it would be good to have more analysis of that. Is that roughly
correct? Do you think
there is a problem with the current key schedule?

-Ekr


On Sat, Feb 17, 2024 at 8:14 AM Muhammad Usama Sardar <
muhammad_usama.sar...@tu-dresden.de> wrote:

> Hi Eric,
>
> Just as a reminder, I did not yet have any answer to the
> questions/concerns posed in [1]. Do you happen to have any strong
> opinion on this or else do you want me to create an issue for this?
>
> Thanks,
>
> Usama
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/ZGmyHwTYh2iPwPrirj_rkSTYhDo/
>
> On 17.02.24 16:40, Eric Rescorla wrote:
> > Hi folks,
> >
> > I went through the open issues on draft-ietf-tls-rfc8446bis this
> > morning and addressed a few. There are two remaining open
> > issues [0]
> >
> > #1338 client_early_traffic_secret and alert
> > #1339 illegal_parameter vs protocol_version propose-close
> >
> > I intend to close both of these unchanged on 2/29 and publish
> > a ready-for-pubreq version. If you object to these resolutions,
> > please comment on the list or on the issue.
> >
> > -Ekr
> >
> >
> > [0] And an editorial PR.
> >
> >
> >
> >
> >
> > ___
> > 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Status of draft-ietf-tls-rfc8446bis

[Eric Rescorla]

Hi folks,

I went through the open issues on draft-ietf-tls-rfc8446bis this
morning and addressed a few. There are two remaining open
issues [0]

#1338 client_early_traffic_secret and alert
#1339 illegal_parameter vs protocol_version propose-close

I intend to close both of these unchanged on 2/29 and publish
a ready-for-pubreq version. If you object to these resolutions,
please comment on the list or on the issue.

-Ekr


[0] And an editorial PR.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] Chempat-X: hybrid of X25519 and sntrup761

[Eric Rescorla]

Hi folks,

Replying to DJB's email but not really in direct response to him.

I'm not a cryptographer and don't have a strong opinion on the
technical merits of X-wing in particular, but I've been following
this thread (lots of messages) and was hoping to try to summarize
what I think is common ground and locate the points of contention.

Does anyone disagree with the following claims?

- X-wing depends on certain properties of the ML-KEM which aren't
  generically true of all KEMs, so if we just substituted in another
  KEM it might not be safe (assuming for the purposes of this
  discussion that sntrup761 and X25519 behave as advertised).

- When used in TLS 1.3, this dependency is relaxed because TLS 1.3
  hashes the whole transcript into the key.

- The combiner that DJB proposes would also relax this dependency at
  some performance cost (see below) and should otherwise be as safe as
  X-wing.


I also think that people agree about the design principle that the
CFRG should propose a specific set of hybrid algorithms that are safe
to use in most if not all contexts and do not require the users to be
aware of the specific internal details of how they are put together.
So, for instance, if CFRG were to specify two hybrids: X25519/ML-KEM
and X448/ML-KEM, it shouldn't matter to protocols whether these use
the same or different combiners or other internal structure.

Similarly, I think people agree that even if we have a generic
combiner that CFRG uses for multiple input algorithms, we should
discourage people from doing so with novel algorithms (though
perhaps we know that people will probably do this whether or not CFRG
publishes such a combiner).


Hopefully, this brings us to the point(s?) of disagreement. Unless
I've misunderstood, the question is (1) Whether it would be better to
use a somewhat safer generic combiner even when we don't believe it's
necessary, even at some performance cost; (2) and if the answer to (1)
is "yes" then what cost would be acceptable; and (3) what is the
actual incremental cost of doing that.

Is this a fair summary?

-Ekr




















On Mon, Jan 29, 2024 at 7:12 AM D. J. Bernstein  wrote:

> Ilari Liusvaara writes:
> > Security review of X-wing only needs to be done once.
>
> "Of course we hope that any particular piece of security review can be
> done just once and that's the end of it (OK Google, please read once
> through the Chrome source code and remove the buffer overflows), but the
> bigger picture is that many security failures are easily explained by
> reviewer overload, so minimizing the complexity of what has to be
> reviewed is a useful default policy. Minimizing TCBs is another example
> of the same approach."
>
> > Generic combiner would likely lead to lots of combinations.
>
> What does "generic" mean here? What's the mechanism that will have a
> "generic" combiner triggering "lots of combinations", and why _won't_
> the same mechanism apply to QSF---the construction presented in the
> X-Wing paper, used in X-Wing, and labeled in the paper as "generic"?
>
> Some arguments seem to be starting from the idea that X-Wing _isn't_
> using a "generic" combiner---but the paper says it is. People seem to
> be using multiple incompatible meanings of the word "generic" here. How
> about we just stop using the word? Any valid argument will survive
> elimination of ambiguous terminology.
>
> The actual technical difference is between (A) combiners making security
> guarantees assuming the input KEM is IND-CCA2 and (B) combiners making
> security guarantees assuming the input KEM is IND-CCA2 and "ciphertext
> collision resistant". (Plus further assumptions in B if the goals of
> https://eprint.iacr.org/2021/708 and https://eprint.iacr.org/2021/1351
> are within scope. The specific A proposals that we're looking at handle
> those goals automatically, since they hash the full public keys.)
>
> > And I think it much easier to understand integrated thing that is unsafe
> > to change than that the component KEMs must be  (oh,
> > and then being used with stuff that fails the requirement).
>
> I agree that what's presented to applications (or to higher-level
> protocols such as TLS) should be a full combined KEM reviewed by CFRG.
> All of the proposals on the table (original X-Wing; X-Wing with the
> modifications that I recommended; Chempat-X) are full combined KEMs.
>
> CFRG approval (or approval by a WG such as TLS) is always for exactly
> the specified mechanism. I don't object to systematically saying so in
> CFRG RFCs---but I also see no evidence that _implementors who read the
> RFCs_ are misunderstanding this in the first place.
>
> Meanwhile there's ample evidence of implementors doing things that specs
> _don't_ allow. Paying attention to how this happens often allows it to
> be predicted and mitigated. This is better---for the end users, which is
> what matters!---than blaming implementors.
>
> Example: there are books and papers stating variable-width ECC 

Re: [TLS] Completion of Update Call for RFC 8773bis

[Eric Rescorla]

Joe,

Does this mean that this draft will be held pending resolution on that
proposal?

-Ekr



On Tue, Jan 23, 2024 at 7:51 AM Joseph Salowey  wrote:

> The working group last call for RFC8773bis has completed
> (draft-ietf-tls-8773bis). There was general support for moving the document
> forward and upgrading its status. However, several working group
> participants raised the concern that formal analysis has not been conducted
> on this modification to the TLS protocol. We should at least have consensus
> on whether this document has the required analysis before upgrading it, but
> we also need a more general statement on this requirement since the TLS
> working group currently does not have a policy for what does and does not
> need formal analysis or what constitutes proper formal analysis.
>
> The chairs are working on a proposal for handling situations like this
> that we plan to post to the list in a week or so.
>
> Thanks,
>
> Joe, Deirdre, and Sean
> ___
> 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] [Errata Held for Document Update] RFC8446 (6205)

[Eric Rescorla]

I believe that the current 8446-bis text addresses this. Martin?

On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System 
wrote:

> The following errata report has been held for document update
> for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6205
>
> --
> Status: Held for Document Update
> Type: Editorial
>
> Reported by: Martin Thomson 
> Date Reported: 2020-06-04
> Held by: Paul Wouters (IESG)
>
> Section: 4.3.2
>
> Original Text
> -
>Servers which are authenticating with a PSK MUST NOT send the
>CertificateRequest message in the main handshake, though they MAY
>send it in post-handshake authentication (see Section 4.6.2) provided
>that the client has sent the "post_handshake_auth" extension (see
>Section 4.2.6).
>
> Corrected Text
> --
>Servers which are authenticating with a resumption PSK MUST NOT send the
>CertificateRequest message in the main handshake, though they MAY
>send it in post-handshake authentication (see Section 4.6.2) provided
>that the client has sent the "post_handshake_auth" extension (see
>Section 4.2.6).  Servers which are authenticating with an external PSK
>MUST NOT send the CertificateRequest message either in the main
> handshake
>or request post-handshake authentication. Future specifications MAY
>provide an extension to permit this.
>
> Notes
> -
> The lack of qualification on "authenticating with a PSK" implies that the
> statement applies equally to both external and resumption PSKs.  However,
> there are two conditions being governed: whether a certificate can be
> requested during the handshake, and whether a certificate can be requested
> post-handshake.  The latter of these requires different rules depending on
> the type of PSK.
>
> We know from the analysis of resumption (see
> https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/)
> that combining a PSK handshake of either type with a client certificate is
> not safe.  Thus, the prohibition on CertificateRequest during the handshake
> applies equally to both resumption and external PSKs.
>
> For post-handshake, Appendix E.1 already discusses the risks of combining
> PSKs with certificates, citing the same analysis as above.
>
>[...]  It is unsafe to use certificate-based client
>authentication when the client might potentially share the same
>PSK/key-id pair with two different endpoints.
>
> For this reason an external PSK is not safe to use with post-handshake
> authentication.  A resumption PSK does not have this property, so the same
> prohibition doesn't apply.
>
> Splitting the requirements as proposed makes this split clearer.
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version
> 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Eric Rescorla]

On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein  wrote:

> Bas Westerbaan writes:
> > X-Wing is a KEM - not a combiner.
>
> Sure, but there's a combiner present inside it---and even advertised:
> see "X-Wing uses the combiner" etc. at the beginning of this thread.
>
> If people are motivated by things like http://tinyurl.com/5cu2j5hf to
> use the same combiner with a different KEM, would they be deterred by a
> presentation purely as a unified package? Or by enough warnings? Maybe,
> but a little more hashing has negligible cost and will reduce the risk.
>
> > Insisting that X-Wing use that generic combiner, is not dissimilar to
> > insisting that every KEM that uses an FO transform, should use the
> > same generic FO transform.
>
> The title and introduction of https://cr.yp.to/papers.html#tightkem
> recommend unifying FO transforms. This would have avoided various
> subsequent breaks of NIST submissions.
>
> To be clear, I think other concerns such as efficiency _can_ outweigh
> the advantages of unification, but this has to be quantified. When I see
> a complaint about "hashing the typically large PQ ciphertexts", I ask
> how this compares quantitatively to communicating the ciphertexts, and
> end up with a cost increment around 1%, which is negligible even in the
> extreme case that the KEM is the main thing the application is doing.
>

Responding to Dan but really this is a question to the draft authors. Do
you agree with Dan on the approximate overhead here?

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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Eric Rescorla]

This is outside the scope of TLSWG, but there's not really a clean mapping
from client->server and server->client packets to requests and responses,
so I would suggest you introduce types that are clearer..

-Ekr


On Mon, Jan 8, 2024 at 9:50 AM JustAnotherArchivist <
justanotherarchiv...@riseup.net> wrote:

> WARC records have 'types' ('WARC-Type' header field), and the two
> relevant ones here are 'request' and 'response'. The names come from
> HTTP of course, but we'd use them analogously for client-to-server and
> server-to-client TLS records, respectively.
>
> ___
> 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] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Eric Rescorla]

On Tue, Jan 2, 2024 at 8:17 PM Benjamin Kaduk  wrote:

> On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote:
> >On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote:
> >
> >  It might be better to describe TLS 1.2 as "overtaken by events". If
> you
> >  want to use CSS Grid or Swift UI (name any newish thing), you'll
> find
> >  yourself with a stack that supports TLS 1.3, so there's no need to
> >  bother with TLS 1.2 in those cases. Turning off TLS 1.2 is
> sometimes a
> >  good idea, because that traffic is composed of undesirable bots in
> many
> >  cases.
> >  I know people also work on things that are old, but it seems ok to
> call
> >  them really old, because that is true. No one seems to disagree with
> >  this point in the draft: "TLS 1.3 [TLS13] is also in widespread use
> and
> >  fixes most known deficiencies with TLS 1.2".
> >  If you think this draft is so strict that it will be ignored, you
> have
> >  nothing to worry about.
> >
> >The issue I am concerned about is that:
> >1. Implementors who do not want to upgrade to TLS 1.3 will implement
> new
> >cipher suites
> >2. IANA will refuse to register the new cipher suites
> >With the result being potential code point collisions.
>
> I share this concern.
>

In the interest of clarity,  I favor the WG declining to work on extending
TLS 1.2, so these cipher suites should be marked as Recommended=No. I'm
just concerned that closing the registries entirely will not have the best
results.

-Ekr

-Ben
>
> ___
> 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] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Eric Rescorla]

On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre  wrote:

> It might be better to describe TLS 1.2 as "overtaken by events". If you
> want to use CSS Grid or Swift UI (name any newish thing), you'll find
> yourself with a stack that supports TLS 1.3, so there's no need to bother
> with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a good idea,
> because that traffic is composed of undesirable bots in many cases.
>
> I know people also work on things that are old, but it seems ok to call
> them really old, because that is true. No one seems to disagree with this
> point in the draft: "TLS 1.3 [TLS13] is also in widespread use and fixes
> most known deficiencies with TLS 1.2".
>
> If you think this draft is so strict that it will be ignored, you have
> nothing to worry about.
>

The issue I am concerned about is that:

1. Implementors who do not want to upgrade to TLS 1.3 will implement new
cipher suites
2. IANA will refuse to register the new cipher suites

With the result being potential code point collisions.

-Ekr



>
> thanks,
> Rob
>
>
>
>
> On Tue, Jan 2, 2024 at 1:19 PM Martin Thomson  wrote:
>
>> On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote:
>> > That is not what the just-adopted draft says.  It says that except for
>> > ALPN and exporters that no new registrations will be accepted for TLS
>> > 1.2 and that new entries should have a Note comment that says “for TLS
>> > 1.3 or later”. This is a change in the current policy.  It has always
>> > said this; see page 3 of [1].
>>
>> I should learn to read the IANA considerations.  This current says:
>>
>> > IANA will stop accepting registrations for any TLS parameters
>> [TLS13REG] except for the following
>>
>> Aside from the fact that the wording also says that IANA will stop
>> accepting TLS 1.3 registrations too, I think that this is a very bad idea.
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Eric Rescorla]

On Tue, Jan 2, 2024 at 6:20 AM Salz, Rich  wrote:

> I'm not Martin, but I believe that his point is that both TLS ciphersuites
> and TLS supported groups/EC curves permit registration outside of the IETF
> process based on the existence of.a specification. As long as PQC can fit
> into new ciphersuites and group types, then anyone can specify it for TLS
> 1.2, and it would in fact be TLS, just not standardized or Recommended.
>
>
>
> That is not what the just-adopted draft says.  It says that except for
> ALPN and exporters that no new registrations will be accepted for TLS 1.2
> and that new entries should have a Note comment that says “for TLS 1.3 or
> later”. This is a change in the current policy.  It has always said this;
> see page 3 of [1].
>

I agree that's clear. Not sure how I misunderstood that, but in that case,
I think that this may be going too far, for the usual reasons why it's not
helpful to restrict IANA registrations of new stuff.

Don't we expect this just to result in squatting.

-Ekr


>
>
> At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has
> so little deployment[4]. This has complicated the wording of the above
> statement, which was raised at [2] and [3]
>
>
>
> [1]
> https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00
>
> [2] https://github.com/richsalz/tls12-frozen/issues/10
>
> [3] https://github.com/richsalz/tls12-frozen/pull/13
>
> [4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/
>
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Eric Rescorla]

On Mon, Jan 1, 2024 at 7:05 PM Rob Sayre  wrote:

> Martin,
>
> You haven’t formed a complete sentence here. That’s usually allowable, but
> not in this instance.
>
> Uri said there might be “special cases”. Anyone can make TLS 1.2 PQ, it
> just won’t be called TLS.
>

I'm not Martin, but I believe that his point is that both TLS ciphersuites
and TLS supported groups/EC curves permit registration outside of the IETF
process based on the existence of.a specification. As long as PQC can fit
into new ciphersuites and group types, then anyone can specify it for TLS
1.2, and it would in fact be TLS, just not standardized or Recommended.

-Ekr


> thanks,
> Rob
>
> On Mon, Jan 1, 2024 at 17:56 Martin Thomson  wrote:
>
>>
>>
>> On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote:
>> > Of course.  We’re not the protocol police and nobody from the IETF will
>> > come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But
>> > with this document, they will not be able to register such an algorithm
>> > for 1.2
>>
>> I don’t think we can go that far. Our registry policies would allow
>> someone else to define something PQC-ish we are only saying that we
>> .intend. to not define something with “official” standing.
>>
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Eric Rescorla]

On Sun, Dec 24, 2023 at 8:46 PM arkiver  wrote:

> Thank you for your replies Eric and Rich, and thank you for looking into
> this with me! I will reply to you both in this message (divided in sections
> due to length).
>

That actually isn't that helpful, because it means that I need to trim the
message to respond.


> In CC is JAA (JustAnotherArchivist), a long time member of Archive Team
> and very experienced with the WARC format - JAA checked this email before
> sending it out.
>
> ---
>
> > - You shouldn't define different URIs for SSL and TLS. SSLv3 and TLS <
> 1.3 are essentially the same protocol, and SSLv2 has been deprecated for
> many years.
>
> While SSLv2 has been deprecated for some time, it is technically possible
> to use it. I think an archive format like WARC should support it.
>
> My idea of a web archive format is that we do not want to support only the
> currently most used modern protocols, but also the earlier (obsolete)
> versions, as they may still be used somewhere and we have to take them into
> account during archiving. Else we have to exclude certain data from being
> archived and might make it more difficult in the future to allow for this
> data be archived, or create confusion when support for archiving this data
> is added eventually.
>

There are two points here.

1. Whether you should have a single URI scheme.
2. Whether you should support SSLv2.

My primary point is that if you must have a URI, you should have only a
single URI scheme, with some parameter to indicate the protocol version. I
don't feel strongly about whether you support SSLv2, but it's not merely
obsolete, it's 20+ years obsolete, not supported by any major browser, and
so there's not really any significant amount of usage in the wild.



> > - It should not have a generic name like "ssl" or "tls". That will
> confuse people and there's no sense in which you would use it to initiate a
> TLS connection.
>
> > Like Eric, I don’t see why a URI is needed and look forward to your
> explanation.  If it is required, then I strongly suggest you use a URN
> under your own “warc” prefix.
>
> Somewhat central to a WARC record is the URI. It shows the location and
> connection over which data was received. It is for example also the main
> header from WARC records to index and find information with in these WARC
> files. For me, "tls://archive.org:443" would describe "data received over
> a TLS connection at archive.org:443", but if it is better described as
> "URI used to initiate a TLS conversation", then it indeed makes better
> sense to use something else, like "urn:warc:tls:archive.org:443".
>

Well, the URI used to retrieve the data isn't "tls:" but rather "https:".
In any case, it's not appropriate to register a generic "tls:" URI for this
use case.

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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Eric Rescorla]

Can you explain why a URI type needs to be defined?
If one needs to be defined, then:

- It should not have a generic name like "ssl" or "tls". That will confuse
people and there's no sense in which you would use it to initiate a TLS
connection.
- You shouldn't define different URIs for SSL and TLS. SSLv3 and TLS < 1.3
are essentially the same protocol, and SSLv2 has been deprecated for many
years.

-Ekr


On Wed, Dec 20, 2023 at 12:17 PM arkiver  wrote:

> Hi TLS Working Group,
>
> This is a question about media types and URIs that are not defined for TLS
> and SSL in their RFCs. I would like to define and start using these, if the
> proposed definition looks reasonable. First a short introduction on what we
> would use this for, and then the proposed definitions.
>
> The [WARC (Web ARChive) format](
> https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/)
> is widely used in web archiving. Traditionally only HTTP requests and
> responses would be stored in a WARC file, with the idea that storing both
> the original requests and responses provides enough information on why and
> how certain data was returned by a web server.
>
> Nowadays we see examples of web servers that employ TLS fingerprinting to
> serve different HTTP responses. In that case storing just the HTTP request
> is not enough to explain a response.
>
> [Wget-AT](https://github.com/ArchiveTeam/wget-lua) is a modified version
> of Wget used to archive hundreds of millions of web resources every day.
> With the release of [Wget-AT 20231213.01](
> https://github.com/ArchiveTeam/wget-lua/releases/tag/v1.21.3-at.20231213.01)
> recording of minimal information about the used TLS session was implemented
> - simply the used cipher suite and the used SSL/TLS protocol. Recording of
> the cipher suite is also being discussed at
> https://github.com/iipc/warc-specifications/issues/86.
>
> A next step in recording SSL/TLS session information would be storing
> certificates and SSL/TLS records.
>
> To record the incoming and outgoing SSL/TLS records, one could use records
> similar to how HTTP requests and responses are stored. However, a URI and
> Media Type need to be defined. These are not defined in [RFC 8446](
> https://datatracker.ietf.org/doc/html/rfc8446).
>
> I would like to propose the following.
>
> For TLS records as defined in [RFC 8446 section B.1.](
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.1) we would use
> the following media type
> >   Media Type name: application
> >   Media subtype name:  tls
> >   Required parameters: version
> >version: The human readable protocol version of the TLS
> > record. Which at the moment may have the values
> > "1.0", "1.1", "1.2", or "1.3".
> >   Optional parameters: contenttype
> >contenttype: The content type of the record, which in the
> > case of TLS 1.3 may be one of "change_cipher_spec",
> > "alert", "handshake", "application_data", or "heartbeat".
>
> The "contenttype" is an optional parameter so a SSL/TLS record can be
> easily identified as being part of a handshake or not, without having the
> parse the (different versions of) SSL/TLS records. An alternative parameter
> name like "content_type" could also be used, but "contenttype" was chosen
> since [RFC 2616 section 19.1.](
> https://datatracker.ietf.org/doc/html/rfc2616#section-19.1) uses
> "msgtype", and not "msg_type".
>
> The URI for TLS records would be
> >   "tls://" host ":" port
> This is inspired by [RFC 3986](
> https://datatracker.ietf.org/doc/html/rfc3986).
>
> Similarly for SSL records we would use as Media Type
> >   Media Type name: application
> >   Media subtype name:  ssl
> >   Required parameters: version
> >version: The human readable protocol version of the SSL
> > record. Which has one of the values "2.0" or "3.0".
> >   Optional parameters: contenttype
> >contenttype: The content type of the record as defined in
> > [RFC 6101 section 5.2.1.](
> https://datatracker.ietf.org/doc/html/rfc6101#section-5.2.1)
> > and which is one of "change_cipher_spec",
> > "alert", "handshake", or "application_data", for
> > SSL 3.0.
> > For SSL 2.0, the "contenttype" would have as value
> > one of "handshake", "security_escape", or
> > "application_data", derived from the text at
> > [The SSL Protocol section 4.1.1.](
> https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00.txt#section-4.1.1
> ).
>
> The SSL URI would be (similar to the TLS URI)
> >   "ssl://" host ":" port
>
> This is currently not in an RFC, but we would like to start using it for
> writing WARC files. Does the use of these two Media Types and URIs make
> sense, or are there obvious problems with 

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Eric Rescorla]

Thanks. This is interesting, but I think we should have a higher standard
than informal reasoning.

We know that there have been challenges around the composition of PSK and
certificates in the past (see Appendix E.1 of RFC 8446), so I think that's
especially true in this case.

-Ekr


On Tue, Dec 5, 2023 at 8:13 AM Russ Housley  wrote:

> At IETF 104, I presented a slide with informal reasoning about TLS 1.3
> Security.
>
> Authentication:
> The certificate processing is exactly the same. It is not better or worse.
>
> Key Schedule computation of Early Secret:
>
> – Initial Handshake
> Without extension: HKDF-Extract(0, 0)
> With extension: HKDF-Extract(ExternalPSK, 0)
>
> – Subsequent Handshake No changes.
>
> Conclusion: Any entropy contributed by the External PSK can only make the
> Early Secret better; the External PSK cannot make it worse.
>
> I will be glad to work with someone that already has things set up for TLS
> 1.3 without this extension to do a more formal analysis.
>
> Russ
>
>
> On Dec 3, 2023, at 5:00 PM, Eric Rescorla  wrote:
>
> To respond directly to the call: I think we should require some level of
> formal analysis for this kind of extension.
>
> If there is some, I think the WG should look at it to determine whether
> it's sufficient. If there isn't I think this should remain at experimental.
> Not having a normative downref is not a good reason; those are trivial to
> manage.
>
> -Ekr
>
>
> On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly 
> wrote:
>
>> Whoops wrong one, strike that
>>
>> On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
>> wrote:
>>
>>> At least one bit of work:
>>> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>>>
>>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:
>>>
>>>> What do we have in terms of formal analysis for this extension?
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
>>>> wrote:
>>>>
>>>>> I think this should move forward.  I am encouraged that at least two
>>>>> people have spoken to me about their implementations.
>>>>>
>>>>> Russ
>>>>>
>>>>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>>>>>
>>>>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
>>>>> an External Pre-Shared Key) was originally published as experimental due 
>>>>> to
>>>>> lack of implementations. As part of implementation work for the EMU
>>>>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>>>>> ongoing implementation work. Since the implementation status of RFC 8773 
>>>>> is
>>>>> changing, this is a consensus call to move RFC 8773 to standards track as
>>>>> reflected in [RFC8773bis](
>>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
>>>>> also help avoid downref for the EMU draft.  Please indicate if you approve
>>>>> of or object to this transition to standards track status by December 15,
>>>>> 2023.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Joe, Sean, and Deirdre
>>>>>
>>>>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Eric Rescorla]

To respond directly to the call: I think we should require some level of
formal analysis for this kind of extension.

If there is some, I think the WG should look at it to determine whether
it's sufficient. If there isn't I think this should remain at experimental.
Not having a normative downref is not a good reason; those are trivial to
manage.

-Ekr


On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly 
wrote:

> Whoops wrong one, strike that
>
> On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
> wrote:
>
>> At least one bit of work:
>> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>>
>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:
>>
>>> What do we have in terms of formal analysis for this extension?
>>>
>>> -Ekr
>>>
>>>
>>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
>>> wrote:
>>>
>>>> I think this should move forward.  I am encouraged that at least two
>>>> people have spoken to me about their implementations.
>>>>
>>>> Russ
>>>>
>>>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>>>>
>>>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
>>>> an External Pre-Shared Key) was originally published as experimental due to
>>>> lack of implementations. As part of implementation work for the EMU
>>>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>>>> ongoing implementation work. Since the implementation status of RFC 8773 is
>>>> changing, this is a consensus call to move RFC 8773 to standards track as
>>>> reflected in [RFC8773bis](
>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
>>>> also help avoid downref for the EMU draft.  Please indicate if you approve
>>>> of or object to this transition to standards track status by December 15,
>>>> 2023.
>>>>
>>>> Thanks,
>>>>
>>>> Joe, Sean, and Deirdre
>>>> ___
>>>> 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 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 to Move RFC 8773 from Experimental to Standards Track

[Eric Rescorla]

What do we have in terms of formal analysis for this extension?

-Ekr


On Fri, Dec 1, 2023 at 11:40 AM Russ Housley  wrote:

> I think this should move forward.  I am encouraged that at least two
> people have spoken to me about their implementations.
>
> Russ
>
> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
> External Pre-Shared Key) was originally published as experimental due to
> lack of implementations. As part of implementation work for the EMU
> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
> ongoing implementation work. Since the implementation status of RFC 8773 is
> changing, this is a consensus call to move RFC 8773 to standards track as
> reflected in [RFC8773bis](
> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will also
> help avoid downref for the EMU draft.  Please indicate if you approve of or
> object to this transition to standards track status by December 15, 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
> ___
> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[Eric Rescorla]

I agree that it would be good to require replay protection at this time.
Perhaps we should just publish a short RFC requiring it.

-Ekr


On Tue, Nov 28, 2023 at 3:00 PM John Mattsson  wrote:

> Hi,
>
>
>
> Lack of replay also enables tracking of client and server. If the client
> or server is a device moving together with a person this enables tracking
> of the person.
>
>
>
> An attacker can store a message from one location and then replay it to
> the client or server in another location. If the client or server accept
> the replayed message, the attacker knows that the device in the two
> locations are one and the same. It is best practice to assume that an
> attacker can always detect if a message was accepted. If the client or
> server send a response to the replayed message (like a replayed client
> authentication request) this is trivial.
>
>
>
> This is different from the attack described in Section C.4 “Client and
> Server Tracking Prevention” of RFC8446bis, which describes the client
> reusing a ticket. A network attacker mounting a replay attack are described
> in Section 8 of RFC8446bis. I think a sentence or two should be added to
> Section C.4 to describe that a network attacker mounting a replay attack
> can be used for server tracking and that the mitigations in Section 8 help.
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> *From: *TLS  on behalf of John Mattsson
> 
> *Date: *Tuesday, 28 November 2023 at 09:30
> *To: *TLS@ietf.org 
> *Subject: *Re: [TLS] DTLS 1.3 replay protection of post-handshake
> messages?
>
> Hi,
>
>
>
> Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than
> that replay protection may be disabled for all records. This is not a
> problem for the initial lock-step handshake, alerts, KeyUpdate, and ACKs.
> It seems to be a major problem for NewSessionTicket, NewConnectionId,
> RequestConnectionId, and Post-handshake client authentication as the lack
> of replay protection might significantly affect availability. It seems to
> me that DTLS 1.3 forgot to update replay protection based on the new
> post-handshake messages. Let me know if I miss something.
>
>
>
> It is a bit surprising that DTLS 1.3 published in 2022 allows the
> application to turn off replay protection at all. This very far from
> current best practice for security protocols. There are very good reasons
> why Datagram QUIC mandates replay protection and why TLS 1.3 has several
> pages discussing security considerations for 0-RTT data, which lacks replay
> protection. In general, turning off replay protection (even just for
> application data) might lead to loss of confidentiality, integrity, and
> availability, i.e., the whole CIA triad.
>
>
>
> Applications cannot be expected to understand the severe consequences of
> not having replay protection or understand how to fix it on the application
> layer. I also don't see any need for turning off replay protection except
> RFC 6083 which is a bit of a special case, and which turned out to have
> replay issues.
>
>
> https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00
>
>
>
> I would strongly recommend all DTLS 1.3 libraries to completely remove the
> option to disable replay protection.
>
>
>
> An easy fix for the post-handshake messages is to "clarify" that replay
> protection must not be turned off for anything else than application data.
> I you agree I can submit an “erratum” for RFC 9147. But this does not solve
> the general issue that turning off replay protection would be a major
> security problem in almost all applications.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> *From: *TLS  on behalf of John Mattsson
> 
> *Date: *Friday, 24 November 2023 at 14:50
> *To: *TLS@ietf.org 
> *Subject: *[TLS] DTLS 1.3 replay protection of post-handshake messages?
>
> Hi,
>
>
>
> How does replay protection of Post-handshake messages work in DTLS 1.3 if
> the per-record replay-protection mechanism is turned off?
>
>
>
> 1. Is the post-handshake messages replay protected in some other way,
> which I miss?
>
>
>
> 2. Should RFC 9147 state that the per-record replay-protection mechanism
> can only be turned off for application data? (I could not find anything in
> RFC 9147 stating something like this).
>
>
>
> (things like post-handshake authentication need replay protection in some
> way)
>
>
>
> Cheers,
>
> John Preuß Mattsson
> ___
> 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] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Eric Rescorla]

Hi David,

Thanks for posting this and for the discussion on the list.

Before commenting on this proposal, I'd like to make sure we're all
on the same page about the situation.


# Background

1. RFC 8446 states that both supported_groups and key_shares
   are in client's preference order but doesn't say what it
   means for a value to be omitted from key_shares.

   When sent by the client, the "supported_groups" extension indicates
   the named groups which the client supports for key exchange, ordered
   from most preferred to least preferred.

   ...

   client_shares:  A list of offered KeyShareEntry values in descending
  order of client preference.

2. Some clients only send a subset of their supported groups in key
   shares, either to save space/computation or because they are
   concerned about compatibility.

3. Some servers negotiate by picking the most preferred key_share
   that is present rather than the most preferred common group in
   supported groups.


When we combine (2) and (3), the result is that the server may
choose a group which is less preferred by both the client and
server because it is included in the key_shares whereas the
more preferred group is not.


# Downgrade

The draft here talks about there being a downgrade issue. ISTM
that there are two things going on here.

1. If the client chooses its key_shares based solely on authenticated
signals, or, as is presently common, consistently for every server,
then the server may choose a suboptimal combination (from the perspective
of group selection, though not from the perspective of latency), but
the attacker cannot influence this selection.

2. If the client chooses its key_shares based on unauthenticated
signals, such as DNS or falling back on apparent network error
(e.g., due to apparent intolerance of large CH), then the attacker
can exploit the behavior described in (3) to downgrade the selected
groups.


Is this a reasonably accurate summary of the situation?

-Ekr




On Tue, Sep 26, 2023 at 9:46 AM David Benjamin 
wrote:

> Hi all,
>
> A while back, we discussed using a DNS hint to predict key shares and
> reduce HelloRetryRequest, but this was dropped due to downgrade issues. In
> thinking through post-quantum KEMs and the various transitions we'll have
> in the future, I realized we actually need to address those downgrade
> issues now. I've published a draft below which is my attempt at resolving
> this.
>
> We don't need a DNS hint for the *current* PQ transition—most TLS
> ecosystems should stick to the one preferred option, and then clients can
> predict that one and move on. However, I think we need to lay the
> groundwork for it now. If today's round of PQ supported groups cannot be
> marked "prediction-safe" (see document for what I mean by that),
> transitioning to the *next* PQ KEM (e.g. if someone someday comes up with
> a smaller one that we're still confident in!) will be extremely difficult
> without introducing downgrades.
>
> Thoughts?
>
> David
>
> -- Forwarded message -
> From: 
> Date: Mon, Sep 25, 2023 at 6:56 PM
> Subject: New Version Notification for
> draft-davidben-tls-key-share-prediction-00.txt
> To: David Benjamin 
>
>
> A new version of Internet-Draft
> draft-davidben-tls-key-share-prediction-00.txt
> has been successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-key-share-prediction
> Revision: 00
> Title:TLS Key Share Prediction
> Date: 2023-09-25
> Group:Individual Submission
> Pages:11
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction
>
>
> Abstract:
>
>This document clarifies an ambiguity in the TLS 1.3 key share
>selection, to avoid a downgrade when server assumptions do not match
>client behavior.  It additionally defines a mechanism for servers to
>communicate key share preferences in DNS.  Clients may use this
>information to reduce TLS handshake round-trips.
>
>
>
> 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] [Technical Errata Reported] RFC8446 (7620)

[Eric Rescorla]

On Sat, Sep 2, 2023 at 4:38 AM Ben Smyth  wrote:

> On Sat, 2 Sept 2023, 13:30 Ben Smyth,  wrote:
>
>> RFC8446 leans towards half closure but doesn't mandate it.
>>
>> [For full closure,] it makes sense for A to just flush the outgoing data
>>>
>>
>> Yes.
>>
>> [For half closure], we want A to continue sending and then eventually
>>> send a close_notify when it has drained its queue.
>>>
>> But this suggests that we can't have a one size fits all rule in TLS and
>>> rather should explain the situation and punt it to the application binding.
>>>
>>
>> Why is this suggested?
>>
>
>
> Oh, perhaps: Because RFC8446 doesn't mandate half closure, implementations
> could either transmit all data and close write, or just close inbound?
>

My point is that the relevant semantics here are application semantics, not
TLS semantics.

Regardless of what TLS says, nothing stops an application protocol from
allowing A to decide it doesn't care what B has to say and sending
close_notify then closing the transport connection. At this point, whatever
the B does is irrelevant because A isn't listening.
TLS 1.2 imposed full close semantics. What TLS 1.3 does is allow
applications to choose *either* full close or half close semantics, but
doesn't have a TLS-level signal of which one the application wants. So, the
application can either have:

- Once the other side sends close_notify, just stop sending ASAP (full
close)
- Once the other side sends close_notify, don't expect anything else, but
send what you want to send (half close).

I think what the text ought to say here is something to the effect of

"Application protocols MAY choose to flush their send buffers and
immediately send a close_notfy upon receiving a close_notify, but this
allows an attacker to influence the data that the peer receives by delaying
the close_notify or by delaying the transport level delivery of the
application's packets. These issues can be addressed at the application
layer, for instance by ignoring packets received after transmitting the
close_notify" [we might need something about only sending close_notify at
appropriate points in the state machine"

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Eric Rescorla]

Thanks. I understand your concern better now.

First, I think it's useful to understand what the truncation being referred
to in this case is. Suppose that A has queued messages M1, M2, ... Mn and
receives the close_notify after it has sent M4. If it responds to the
close_notify by flushing its write queue and sending a close_notify than
M5...Mn will be dropped and hence the stream will be truncated. Note that
the attacker cannot forge the close_notify, so so far this isn't actually
an attack, just a correctness issue, depending on the semantics of the
protocol above. What the attacker can do, however, is:

- Hold the close_notify, thus causing A to send more of the messages
- With a congestion controlled protocol like TCP, slow down As sending
rate. Initially, this will just cause A's packets to be buffered in the
kernel, but they can't be recalled, so this doesn't affect what A sends,
but eventually the kernel buffers might fill up and the application might
stop sending, in which case it might be possible to cause more of A's
stream to be truncated.

Have I missed something?

However, it seems to me that this is actually a somewhat complicated
question that is about application semantics more than about TLS itself.
Specifically, what sementics does the application think the close_notify
embodies, half close or full close? In the latter case, it makes sense for
A to just flush the outgoing data (and in fact, it's not clear that B
really needs A's close_notify). In the former case, we want A to continue
sending and then eventually send a close_notify when it has drained its
queue. But this suggests that we can't have a one size fits all rule in TLS
and rather should explain the situation and punt it to the application
binding.

-Ekr


On Wed, Aug 30, 2023 at 2:42 AM Ben Smyth  wrote:

>
>
> On Tue, 29 Aug 2023, 14:31 Eric Rescorla,  wrote:
>
>> On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth  wrote:
>>
>>>  On Mon, 28 Aug 2023, Eric Rescorla, wrote:
>>>
>>>> ...there are quite a few situations in which endpoints close the
>>>>>> connection before receiving a close_notify, for instance, when they 
>>>>>> receive
>>>>>> an end of data message in the application protocol or when they time out.
>>>>>> The former case is generally safe, the latter is not, but extremely
>>>>>> common, in fact perhaps the dominant caseI'm not sure this is an
>>>>>> erratum as I think it correctly describes the situation and it's a
>>>>>> judgement call whether we ought to have a requirement here or whether 
>>>>>> it's
>>>>>> a 6919 MUST (BUT WE KNOW YOU WON'T)
>>>>>>
>>>>>
>>> TLS 1.2 dictates: Either party may initiate a close by sending a
>>> close_notify alert...The other party MUST respond with a close_notify alert
>>> of its own and close down the connection immediately, discarding any
>>> pending writes.
>>>
>>> RFC 8446-bis could simply forbid that behaviour, e.g., This does not
>>> have any effect on the read side of the sender's connection; a party
>>> receiving a "close_notify" alert MUST NOT respond with a "close_notify"
>>> alert of its own. Note that this is a change from versions of TLS prior to
>>> TLS 1.3 in which receivers were required to react to a "close_notify" by
>>> discarding pending writes and sending an immediate "close_notify" alert of
>>> their own.
>>>
>>
>> I must be missing something, as I don't see how that would help. Perhaps
>> you could provide an example of what it is you are concerned about?
>>
>
> Sure: As-is the specification doesn't mandate against the old behaviour; a
> specification compliant implementation may be vulnerable to the TLS 1.2
> truncation attack arising from closure in both directions. Whilst I
> appreciate the issues raised in this thread, I believe the specification
> could be stricter by mandating against the old behaviour. As-is, hints are
> raised, guidance given, but there's no strict requirement. Perhaps I'm just
> reading too rigorously, there's no need to formally forbid---as an IETF
> outsider, that seems a little lax, I'd expect a change from two-way closure
> to one-way closure to be mandated, thereby explicitly teaching away from a
> known vulnerability. RFC8446-bis is an opportunity to polish the original
> spec.
>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Eric Rescorla]

On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth  wrote:

>  On Mon, 28 Aug 2023, Eric Rescorla, wrote:
>
>> ...there are quite a few situations in which endpoints close the
>>>> connection before receiving a close_notify, for instance, when they receive
>>>> an end of data message in the application protocol or when they time out.
>>>> The former case is generally safe, the latter is not, but extremely
>>>> common, in fact perhaps the dominant caseI'm not sure this is an
>>>> erratum as I think it correctly describes the situation and it's a
>>>> judgement call whether we ought to have a requirement here or whether it's
>>>> a 6919 MUST (BUT WE KNOW YOU WON'T)
>>>>
>>>
> TLS 1.2 dictates: Either party may initiate a close by sending a
> close_notify alert...The other party MUST respond with a close_notify alert
> of its own and close down the connection immediately, discarding any
> pending writes.
>
> RFC 8446-bis could simply forbid that behaviour, e.g., This does not have
> any effect on the read side of the sender's connection; a party receiving a
> "close_notify" alert MUST NOT respond with a "close_notify" alert of its
> own. Note that this is a change from versions of TLS prior to TLS 1.3 in
> which receivers were required to react to a "close_notify" by discarding
> pending writes and sending an immediate "close_notify" alert of their own.
>

I must be missing something, as I don't see how that would help. Perhaps
you could provide an example of what it is you are concerned about?

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Eric Rescorla]

So I'm not sure this is an erratum as I think it correctly describes the
situation and it's a judgement call whether we ought to have a requirement
here or whether it's a 6919 MUST (BUT WE KNOW YOU WON'T)

We are currently preparing the 8446-bis, so I think the right place to have
this discussion is in that context.

-Ekr


On Mon, Aug 28, 2023 at 6:38 AM Ben Smyth  wrote:

> Yes, we agree. I anticipate necessity to reduce the strength my wording
> (or to ignore). I raise this errata only to discuss specification-compliant
> implementations being vulnerable to truncation attack; it'd surely be
> better to have a SHOULD or SHOULD NOT.
>
> On Mon, 28 Aug 2023, 14:43 Eric Rescorla,  wrote:
>
>> Hi Ben,
>>
>> Before addressing the text, let's make sure we are on the same page about
>> the situation.
>>
>> As you probably know, there are quite a few situations in which endpoints
>> close the connection before
>> receiving a close_notify, for instance, when they receive an end of data
>> message in the application
>> protocol or when they time out. The former case is generally safe, the
>> latter is not, but extremely
>> common, in fact perhaps the dominant case. Do we agree on that?
>>
>> -Ekr
>>
>>
>> On Mon, Aug 28, 2023 at 4:02 AM RFC Errata System <
>> rfc-edi...@rfc-editor.org> wrote:
>>
>>> The following errata report has been submitted for RFC8446,
>>> "The Transport Layer Security (TLS) Protocol Version 1.3".
>>>
>>> --
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid7620
>>>
>>> --
>>> Type: Technical
>>> Reported by: Ben Smyth 
>>>
>>> Section: 6.1
>>>
>>> Original Text
>>> -
>>> Each party MUST send a "close_notify" alert before closing its write
>>> side of the connection, unless it has already sent some error alert.
>>> This does not have any effect on its read side of the connection.
>>> Note that this is a change from versions of TLS prior to TLS 1.3 in
>>> which implementations were required to react to a "close_notify" by
>>> discarding pending writes and sending an immediate "close_notify"
>>> alert of their own.  That previous requirement could cause truncation
>>> in the read side.  Both parties need not wait to receive a
>>> "close_notify" alert before closing their read side of the
>>> connection, though doing so would introduce the possibility of
>>> truncation.
>>>
>>> Corrected Text
>>> --
>>> Each party MUST send a "close_notify" alert before closing its write
>>> side of the connection, unless it has already sent some error alert.
>>> This SHOULD NOT have any effect on the read side of the sender's
>>> connection;
>>> parties SHOULD receive a "close_notify" alert before closing the read
>>> side of their connection.
>>> Note that this is a change from versions of TLS prior to TLS 1.3 in
>>> which receivers were required to react to a "close_notify" by
>>> discarding pending writes and sending an immediate "close_notify"
>>> alert of their own.  That previous requirement could cause truncation
>>> in the read side.  Both parties need not wait to receive a
>>> "close_notify" alert before closing their read side of the
>>> connection, though doing so would introduce the possibility of
>>> truncation.
>>>
>>> Notes
>>> -
>>> As-is there's a specification-level vulnerability:
>>> Specification-compliant implementations may be vulnerable to truncation
>>> attacks.
>>>
>>> I suggest using SHOULD NOT & SHOULD for better signposting and to avoid
>>> specification-level vulnerability.
>>>
>>> I also suggest minor tweaks for readability.
>>>
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --
>>> RFC8446 (draft-ietf-tls-tls13-28)
>>> --
>>> Title   : The Transport Layer Security (TLS) Protocol
>>> Version 1.3
>>> Publication Date: August 2018
>>> Author(s)   : E. Rescorla
>>> Category: PROPOSED STANDARD
>>> Source  : Transport Layer Security
>>> Area: Security
>>> Stream  : IETF
>>> Verifying Party : IESG
>>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Eric Rescorla]

Hi Ben,

Before addressing the text, let's make sure we are on the same page about
the situation.

As you probably know, there are quite a few situations in which endpoints
close the connection before
receiving a close_notify, for instance, when they receive an end of data
message in the application
protocol or when they time out. The former case is generally safe, the
latter is not, but extremely
common, in fact perhaps the dominant case. Do we agree on that?

-Ekr


On Mon, Aug 28, 2023 at 4:02 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7620
>
> --
> Type: Technical
> Reported by: Ben Smyth 
>
> Section: 6.1
>
> Original Text
> -
> Each party MUST send a "close_notify" alert before closing its write
> side of the connection, unless it has already sent some error alert.
> This does not have any effect on its read side of the connection.
> Note that this is a change from versions of TLS prior to TLS 1.3 in
> which implementations were required to react to a "close_notify" by
> discarding pending writes and sending an immediate "close_notify"
> alert of their own.  That previous requirement could cause truncation
> in the read side.  Both parties need not wait to receive a
> "close_notify" alert before closing their read side of the
> connection, though doing so would introduce the possibility of
> truncation.
>
> Corrected Text
> --
> Each party MUST send a "close_notify" alert before closing its write
> side of the connection, unless it has already sent some error alert.
> This SHOULD NOT have any effect on the read side of the sender's
> connection;
> parties SHOULD receive a "close_notify" alert before closing the read side
> of their connection.
> Note that this is a change from versions of TLS prior to TLS 1.3 in
> which receivers were required to react to a "close_notify" by
> discarding pending writes and sending an immediate "close_notify"
> alert of their own.  That previous requirement could cause truncation
> in the read side.  Both parties need not wait to receive a
> "close_notify" alert before closing their read side of the
> connection, though doing so would introduce the possibility of
> truncation.
>
> Notes
> -
> As-is there's a specification-level vulnerability: Specification-compliant
> implementations may be vulnerable to truncation attacks.
>
> I suggest using SHOULD NOT & SHOULD for better signposting and to avoid
> specification-level vulnerability.
>
> I also suggest minor tweaks for readability.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version
> 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[Eric Rescorla]

On Mon, Aug 7, 2023 at 2:50 PM Jonathan Lennox 
wrote:

>
>
> On Aug 6, 2023, at 5:22 PM, Rob Sayre  wrote:
>
> On Sun, Aug 6, 2023 at 2:14 PM Eric Rescorla  wrote:
>
>> Sure. Though with that said, DTLS-SRTP should use the same code points
>> for 1.2 and 1.3, so I don't actually know if this is an exception after all.
>>
>
> I think the issue is still there in a spec lawyer kind of way. So, after
> this draft is published, would we say a new DTLS-SRTP cipher suite is
> defined for use in DTLS 1.2?
>
> That seems like the goal of the Github issue.
>
>
> That was indeed the goal of my initial Github issue, but on further
> reflection, I’m more concerned.
>
> As Achim’s mail indicated, as far as I know wolfSSL is the only library
> currently with a released DTLS 1.3 implementation, and many of the other
> common TLS libraries — most notably including the OpenSSL family — don’t
> seem to have any current plans to do so.
>
> If this situation doesn’t change before we need PQ KEMs to enter
> production, then there’ll be no way to protect DTLS-protected traffic —
> notably including WebRTC and other DTLS-SRTP traffic — from
> harvest-now-decrypt-later attacks.
>
> Hopefully the eventual need for PQ support will incentivize stack
> developers to work on DTLS 1.3, but I’m worried.
>
> I don’t know if this would warrant actually defining PQ KEMs for DTLS 1.2
> — will stack implementors implement that if they won’t do DTLS 1.3? — but
> it’s something to think about.
>

These seem like good reasons for stack implementors to do DTLS 1.3.

-Ekr


>
>
> -Ekr
>>
>>
>> On Sun, Aug 6, 2023 at 1:59 PM Rob Sayre  wrote:
>>
>>> On Sun, Aug 6, 2023 at 11:48 AM Eric Rescorla  wrote:
>>>
>>>>
>>>>
>>>> On Sun, Aug 6, 2023 at 9:58 AM Rob Sayre  wrote:
>>>>
>>>>> There's also the fact that the TLS 1.3 was published in August 2018,
>>>>> but DTLS 1.3 wasn't published until April 2022. So, it is kind of
>>>>> reasonable to allow some extra time here.
>>>>>
>>>>> The WG could say this document doesn't apply to DTLS. Another choice
>>>>> would be to say that it does apply to DTLS, but the WG will continue to
>>>>> accept work for DTLS 1.2 that is DTLS-specific. The aim here being that
>>>>> DTLS is not used as an excuse to continue to work on 1.2.
>>>>>
>>>>
>>>> This seems like a fine proposal. However, as a practical matter, there
>>>> are very few changes one could make to DTLS that would not also apply to
>>>> TLS, so aside from DTLS-SRTP cipher suites, I'm not sure how much
>>>> difference it makes.
>>>>
>>>
>>> Makes sense, let's just not try to prove a negative in insisting that
>>> DTLS-SRTP cipher suites are the only such thing.
>>>
>>> "Further, TLS 1.3 use is widespread, and new protocols should require
>>> and assume its existence. DTLS 1.3 is a newer specification. New
>>> algorithms or extensions that apply solely to DTLS, such as DTLS-SRTP
>>> cipher suites, will be considered for DTLS 1.2."
>>>
>>> thanks,
>>> Rob
>>>
>>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[Eric Rescorla]

Sure. Though with that said, DTLS-SRTP should use the same code points for
1.2 and 1.3, so I don't actually know if this is an exception after all.

-Ekr


On Sun, Aug 6, 2023 at 1:59 PM Rob Sayre  wrote:

> On Sun, Aug 6, 2023 at 11:48 AM Eric Rescorla  wrote:
>
>>
>>
>> On Sun, Aug 6, 2023 at 9:58 AM Rob Sayre  wrote:
>>
>>> There's also the fact that the TLS 1.3 was published in August 2018, but
>>> DTLS 1.3 wasn't published until April 2022. So, it is kind of reasonable to
>>> allow some extra time here.
>>>
>>> The WG could say this document doesn't apply to DTLS. Another choice
>>> would be to say that it does apply to DTLS, but the WG will continue to
>>> accept work for DTLS 1.2 that is DTLS-specific. The aim here being that
>>> DTLS is not used as an excuse to continue to work on 1.2.
>>>
>>
>> This seems like a fine proposal. However, as a practical matter, there
>> are very few changes one could make to DTLS that would not also apply to
>> TLS, so aside from DTLS-SRTP cipher suites, I'm not sure how much
>> difference it makes.
>>
>
> Makes sense, let's just not try to prove a negative in insisting that
> DTLS-SRTP cipher suites are the only such thing.
>
> "Further, TLS 1.3 use is widespread, and new protocols should require and
> assume its existence. DTLS 1.3 is a newer specification. New algorithms
> or extensions that apply solely to DTLS, such as DTLS-SRTP cipher suites,
> will be considered for DTLS 1.2."
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[Eric Rescorla]

On Sun, Aug 6, 2023 at 9:58 AM Rob Sayre  wrote:

> There's also the fact that the TLS 1.3 was published in August 2018, but
> DTLS 1.3 wasn't published until April 2022. So, it is kind of reasonable to
> allow some extra time here.
>
> The WG could say this document doesn't apply to DTLS. Another choice would
> be to say that it does apply to DTLS, but the WG will continue to accept
> work for DTLS 1.2 that is DTLS-specific. The aim here being that DTLS is
> not used as an excuse to continue to work on 1.2.
>

This seems like a fine proposal. However, as a practical matter, there are
very few changes one could make to DTLS that would not also apply to TLS,
so aside from DTLS-SRTP cipher suites, I'm not sure how much difference it
makes.

-Ekr


>
> thanks,
> Rob
>
>
> On Sun, Aug 6, 2023 at 8:28 AM Achim Kraus  wrote:
>
>> I don't have a complete overview, but AFAIK:
>>
>> - wolfSSL (C) has DTLS 1.3
>>
>> - mbedTLS (C) for now doesn't support it
>>
>> - pion/dtls (GO) for now doesn't support it
>>
>> - Eclipse/tinydtls (C) doesn't support it
>>
>> - Eclipse/Californium (Java) doesn't support it
>>
>> best regards
>> Achim
>>
>> Am 06.08.23 um 17:01 schrieb Salz, Rich:
>> > Quoting https://github.com/richsalz/tls12-frozen/issues/7
>> >  raised by Jonathan
>> > Lennox, in its entirety:
>> >
>> > “Given the slow progress of implementations of DTLS 1.3, I think this
>> > draft needs to be clear that this feature freeze applies only to TLS 1.2
>> > proper, not DTLS 1.2.
>> >
>> > “For example, I would be very sad if any new DTLS-SRTP protection
>> > profiles could only be negotiated with DTLS 1.3.
>> >
>> > “This may have implications for the IANA instructions section, for
>> > registries that are shared between the two protocols.”
>> >
>> > Does the WG have any vews?  I know OpenSSL isn’t doing DTLS 1.3 right
>> > now, but is the industry overall lagging? Should we allow changes to
>> > DTLS 1.2?
>> >
>> >
>> > ___
>> > 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 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] [EXTERNAL] Adoption call for draft-jackson-tls-cert-abridge

[Eric Rescorla]

I support adoption and am willing to review.

On Tue, Aug 1, 2023 at 12:38 PM Andrei Popov  wrote:

> I support adoption.
>
> Cheers,
>
> Andrei Popov
>
> -Original Message-
> From: TLS  On Behalf Of Christopher Wood
> Sent: Tuesday, August 1, 2023 12:36 PM
> To: TLS@ietf.org
> Subject: [EXTERNAL] [TLS] Adoption call for draft-jackson-tls-cert-abridge
>
> Hi all,
>
> Based on positive feedback received during IETF 117, this email begins an
> adoption call for "Abridged Compression for WebPKI Certificates"
> (draft-jackson-tls-cert-abridge).
>
> The datatracker page for this document can be found here:
> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
>
> And the GitHub repository can be found here:
> https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
>
> Please indicate whether or not your support adoption of this document in
> its current state. Procedure questions raised during the WG meeting last
> week can be ironed out in the event of this item being adopted.
>
> This call for adoption will conclude on August 16.
>
> Thanks,
> Chris, for the chairs
> ___
> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Tue, Jul 11, 2023 at 2:09 PM Dennis Jackson 
wrote:

> On 11/07/2023 21:17, Eric Rescorla wrote:
>
> I wouldn't want to 'permanently' encode the root programs, CT
> trusted log lists or end entity compressed extensions for example.
>
>
> Arguably it will be necessary to encode the database in the final RFC.
> Otherwise, you have what is effectively a normative reference to the
> contents of the CCADB.
>
> I haven't thought through this completely, but I mention it because it
> may affect the rest of the design decisions if we end up with the
> WG having to produce the database.
>
> To clarify: I'm fine with encoding things permanently in an RFC for use
> with a specific code point. I just wouldn't want to do that for multiple
> future code points to be used in future years since predicting developments
> is inherently hard.
>

That seems sensible.

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

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Tue, Jul 11, 2023 at 12:45 PM Dennis Jackson  wrote:

> On 11/07/2023 15:48, Thom Wiggers wrote:
>
> > I enjoyed reading this draft. I think it is well-written. Aside from
> > some to-be-figured-out details that have already been pointed out, it
> > seems very practical, which is rather nice.
> Thanks!
> >
> > The one thing that makes me frown a bit is the intended versioning
> > scheme. I don't think consuming identifiers is a problem, but perhaps
> > we can pre-define the code points and variables for the next, say,
> > N=0xff years? Then the versioning mechanism is set for the foreseeable
> > future.
>
> I like the reduction of bookkeeping but I think we would need to work
> out which parts of the construction to make dynamic with an IANA
> registry. I wouldn't want to 'permanently' encode the root programs, CT
> trusted log lists or end entity compressed extensions for example.
>
> I don't really have a sense of what the idiomatic IETF solution is for
> this problem, so I settled for seemed like the least commitment method
> in the draft.
>

Arguably it will be necessary to encode the database in the final RFC.
Otherwise, you have what is effectively a normative reference to the
contents of the CCADB.

I haven't thought through this completely, but I mention it because it
may affect the rest of the design decisions if we end up with the
WG having to produce the database.

> (You could even say that we wrap the code points after N years).
>
> I don't know whether there'll be interest in using this scheme outside
> TLS (e.g. reducing storage / bandwidth costs in CT) but if there is then
> we'll probably want identifiers which are unambiguous over long timescales.
>

I'm not worried about code point exhaustion. Say we issued a new version
every 3 months and allocated a block of 256 code points, we would be
able to go without changes for 64 years.

-Ekr


>
> Best,
> Dennis
>
> ___
> 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] Abridged Certificate Compression

[Eric Rescorla]

On Mon, Jul 10, 2023 at 10:54 AM Dennis Jackson 
wrote:

>
> On 07/07/2023 21:28, Eric Rescorla wrote:
>
> S 3.2.1
>> How much value are you getting from the CT logs? It seems like
>> additional complexity. I agree with your comment about having
>> this submitted to CCADB.
>>
>> It seemed the fairest repeatable way to check whether a CA was offering
>> certificates to WebPKI clients without having to write a lot of emails. I
>> agree its not desirable to keep as a dependency in the long run.
>>
> Can you elaborate on the concern here? I.e., is it that we will
> overinclude or underinclude if we just use CCADB?
>
> Sorry, this answer came out garbled. Using CT gives two things:
>
> 1) There are large extensions in end-entity certs which are specific to
> the issuer and change little between certs. For example, the URLs for OCSP,
> CRL and the practice statement are typically the same. Using CT logs lets
> me pull out an example of each extension for that CA without having to
> write a bunch of mails to ask them to produce them in the right format.
>
> 2) I don't personally have concerns about the dictionary size and would
> prefer to include every CA. However, if someone were to have strong
> feelings about this then using CT to measure popularity is much fairer than
> say scanning popular domains from the Tranco list or whatever.
>
> In the long term, I hope this could just be removed and ideally the CA's
> themselves provide a fixed size binary blob via CCADB that they'd like
> compressed out of their certs.
>
Thanks for the explanation. It sounds like we agree that it would be best
not to have this piece and we just have different assessments of how hard
it will be to get CCADB populated with this data. My sense is that we would
be better off getting the data from CCADB, as CAs will have a clear
incentive to populate it, as their customers will get better performance.
However, I think this is a question the WG is well suited to resolve and
that we could adopt the document as-is and sort this out later.

-Ekr

Best,
> Dennis
>
>
> Thanks,
> -Ekr
>
> S 5.1.
>> ISTM that there are plenty of code points available.
>>
>> Thanks!
>>
>> Best,
>> Dennis
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote:
>>
>>> Hi all,
>>>
>>> I've submitted the draft below that describes a new TLS certificate
>>> compression scheme that I'm calling 'Abridged Certs' for now. The aim is
>>> to deliver excellent compression for existing classical certificate
>>> chains and smooth the transition to PQ certificate chains by eliminating
>>> the root and intermediate certificates from the bytes on the wire. It
>>> uses a shared dictionary constructed from the CA certificates listed in
>>> the CCADB [1] and the associated extensions used in end entity
>>> certificates.
>>>
>>> Abridged Certs compresses the median certificate chain from ~4000 to
>>> ~1000 bytes based on a sample from the Tranco Top 100k. This beats
>>> traditional TLS certificate compression which produces a median of ~3200
>>> bytes when used alone and ~1400 bytes when combined with the outright
>>> removal of CA certificates from the certificate chain. The draft
>>> includes a more detailed evaluation.
>>>
>>> There were a few other key considerations. This draft doesn't impact
>>> trust decisions, require trust in the certificates in the shared
>>> dictionary or involve extra error handling. Nor does the draft favor
>>> popular CAs or websites due to the construction of the shared
>>> dictionary. Finally, most browsers already ship with a complete list of
>>> trusted intermediate and root certificates that this draft reuses to
>>> reduce the client storage footprint to a few kilobytes.
>>>
>>> I would love to get feedback from the working group on whether the draft
>>> is worth developing further.
>>>
>>> For those interested, a few issues are tagged DISCUSS in the body of the
>>> draft, including arrangements for deploying new versions with updated
>>> dictionaries and the tradeoff between equitable CA treatment and the
>>> disk space required on servers (currently 3MB).
>>>
>>> Best,
>>> Dennis
>>>
>>> [1] Mozilla operates the Common CA Database on behalf of Apple,
>>> Microsoft, Google and other members.
>>>
>>> On 06/07/2023 23:11, internet-dra...@ietf.org wrote:
>>> > A new vers

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Fri, Jul 7, 2023 at 1:21 PM Dennis Jackson 
wrote:

> Thank you for the comments. I'll fix most of them - responses inline for
> the rest:
>
> On 07/07/2023 17:38, Eric Rescorla wrote:
>
> S 3.1.2.
>
>7.  Order the list by the date each certificate was included in the
>CCADB, breaking ties with the lexicographic ordering of the
>SHA256 certificate fingerprint.
>
> Would it be simpler to just sort by the hash?
>
> Possibly a premature optimization, but I was thinking that if a new
> version only included new certificates, it'd be nice to only have to append
> the new data to the existing dictionaries. I haven't yet worked out if
> that's actually going to deliver anything useful though.
>

Fair enough.


>
>1.  If so, replace the opaque cert_data member of
>CertificateEntry with its adjusted three byte identifier and
>copy the CertificateEntry structure with corrected lengths to
>the output.
>
> It seems like this is not injective in the face of certificates
> whose length is greater than or equal to 0xff. That's probably
> not a problem, but I think you should make it clear and have some
> way to manage it.
>
> If the length is corrected, isn't the only risk a collision with a
> certificate which is exactly three bytes and starts with 0xff?
>
Ah yes, I had forgotten about the length value. This indeed seems fine.

S 3.2.1
> How much value are you getting from the CT logs? It seems like
> additional complexity. I agree with your comment about having
> this submitted to CCADB.
>
> It seemed the fairest repeatable way to check whether a CA was offering
> certificates to WebPKI clients without having to write a lot of emails. I
> agree its not desirable to keep as a dependency in the long run.
>
Can you elaborate on the concern here? I.e., is it that we will overinclude
or underinclude if we just use CCADB?

Thanks,
-Ekr

S 5.1.
> ISTM that there are plenty of code points available.
>
> Thanks!
>
> Best,
> Dennis
>
>
>
>
>
>
>
>
> On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I've submitted the draft below that describes a new TLS certificate
>> compression scheme that I'm calling 'Abridged Certs' for now. The aim is
>> to deliver excellent compression for existing classical certificate
>> chains and smooth the transition to PQ certificate chains by eliminating
>> the root and intermediate certificates from the bytes on the wire. It
>> uses a shared dictionary constructed from the CA certificates listed in
>> the CCADB [1] and the associated extensions used in end entity
>> certificates.
>>
>> Abridged Certs compresses the median certificate chain from ~4000 to
>> ~1000 bytes based on a sample from the Tranco Top 100k. This beats
>> traditional TLS certificate compression which produces a median of ~3200
>> bytes when used alone and ~1400 bytes when combined with the outright
>> removal of CA certificates from the certificate chain. The draft
>> includes a more detailed evaluation.
>>
>> There were a few other key considerations. This draft doesn't impact
>> trust decisions, require trust in the certificates in the shared
>> dictionary or involve extra error handling. Nor does the draft favor
>> popular CAs or websites due to the construction of the shared
>> dictionary. Finally, most browsers already ship with a complete list of
>> trusted intermediate and root certificates that this draft reuses to
>> reduce the client storage footprint to a few kilobytes.
>>
>> I would love to get feedback from the working group on whether the draft
>> is worth developing further.
>>
>> For those interested, a few issues are tagged DISCUSS in the body of the
>> draft, including arrangements for deploying new versions with updated
>> dictionaries and the tradeoff between equitable CA treatment and the
>> disk space required on servers (currently 3MB).
>>
>> Best,
>> Dennis
>>
>> [1] Mozilla operates the Common CA Database on behalf of Apple,
>> Microsoft, Google and other members.
>>
>> On 06/07/2023 23:11, internet-dra...@ietf.org wrote:
>> > A new version of I-D, draft-jackson-tls-cert-abridge-00.txt
>> > has been successfully submitted by Dennis Jackson and posted to the
>> > IETF repository.
>> >
>> > Name: draft-jackson-tls-cert-abridge
>> > Revision: 00
>> > Title:Abridged Compression for WebPKI Certificates
>> > Document date:2023-07-06
>> > Group: 

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

Document: draft-jackson-tls-cert-abridge-00.txt

Hi Dennis,

Thanks for sending this. This seems like great work and
a big improvement. I have a number of comments below,
mostly minor.


S 1.1.
   The existing compression schemes used in [TLSCertCompress] have been
   shown to deliver a substantial improvement in QUIC handshake latency
   [FastlyStudy], [QUICStudy] by reducing the size of server's
   certificate chain and so fitting the server's initial messages within
   a single flight.  However, in a post-quantum setting, the signatures
   and public keys used in a TLS certificate chain will be typically 10
   to 40 times their current size and cannot be compressed with existing
   TLS Certificate Compression schemes.

Perhaps "because most of the size of the certificate is in high
entropy fields such as cryptographic keys and signatures".


S 1.2.
   This draft introduces a new TLS certificate compression scheme
   [TLSCertCompress] which is intended specifically for WebPKI
   applications.  It uses a predistributed dictionary consisting of all

I would note specifically at this point that this fits into the existing
compression scheme negotiation structure, as one otherwise needs
to look to see what TLSCertCompress goes to.

   Note that as this is only a compression scheme, it does not impact
   any trust decisions in the TLS handshake.  A client can offer this
   compression scheme whilst only trusting a subset of the certificates
   in the CCADB certificate listing, similarly a server can offer this
   compression scheme whilst using a certificate chain which does not
   chain back to a WebPKI root.  Furthermore, new root certificates are
   typically included in the CCADB at the start of their application to
   a root store, a process which typically takes more than a year.
   Consequently, applicant root certificates can be added to new
   versions of this scheme ahead of any trust decisions, allowing new
   CAs to compete on equal terms with existing CAs.

Perhaps add "as soon as they are approvedfor entry into the root
program."

S 1.3.
   CBOR Encoded X.509 (C509) [I-D.ietf-cose-cbor-encoded-cert-05]
   defines a concise alternative format for X.509 certificates.  If this
   format were to become widely used on the WebPKI, defining an
   alternative version of this draft specifically for C509 certificates
   would be beneficial.

Just for clarity "if C509 certificates" because I initially
read "this format" as the scheme defined in this document.


S 3.1.2.
   7.  Order the list by the date each certificate was included in the
   CCADB, breaking ties with the lexicographic ordering of the
   SHA256 certificate fingerprint.

Would it be simpler to just sort by the hash?

   1.  If so, replace the opaque cert_data member of
   CertificateEntry with its adjusted three byte identifier and
   copy the CertificateEntry structure with corrected lengths to
   the output.

It seems like this is not injective in the face of certificates
whose length is greater than or equal to 0xff. That's probably
not a problem, but I think you should make it clear and have some
way to manage it.

   The decompression algorithm requires the above steps but in reverse,
   swapping any recognized three-byte identifier in a cert_data field
   with the DER representation of the associated certificate and
   updating the lengths.  Unrecognized three-byte identifiers are
   ignored.  If the compressed certificate chain cannot be parsed (e.g.
   due to incorrect length fields) the decompression algorithm SHOULD
   return the sentinel value 0xff.  Note that the connection will fail
   regardless even if this step is not taken as neither certificate
   validation nor transcript validation can succeed.

Instead of a sentinel, why not just return an error?

S 3.2.1
How much value are you getting from the CT logs? It seems like
additional complexity. I agree with your comment about having
this submitted to CCADB.

S 3.2.1.1.
   These parameters are recommended in order to achieve the best
   compression ratio however implementations MAY use their preferred
   parameters as these parameters are not used during decompression.

Perhaps "as long as the value of those parameters does not influence
decompression".


S 5.1.
ISTM that there are plenty of code points available.







On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson  wrote:

> Hi all,
>
> I've submitted the draft below that describes a new TLS certificate
> compression scheme that I'm calling 'Abridged Certs' for now. The aim is
> to deliver excellent compression for existing classical certificate
> chains and smooth the transition to PQ certificate chains by eliminating
> the root and intermediate certificates from the bytes on the wire. It
> uses a shared dictionary constructed from the CA certificates listed in
> the CCADB [1] and the associated extensions used in end entity
> certificates.
>
> Abridged Certs compresses the median 

Re: [TLS] Tricking TLS library into crypto primitives library

[Eric Rescorla]

I believe https://cryptography.io/en/latest/ is what you want.

TLS does not use AES in a way that is consistent with what you would get if
you just used a typical AES library.
-Ekr


On Sun, Jun 25, 2023 at 10:21 AM Soni L.  wrote:

> Python doesn't expose raw AES, etc. But it does expose a fairly rich TLS
> library. Wondering if it would be possible to just connect a TLS socket to
> a raw TCP socket and somehow write bytes into TLS and get ciphertext out or
> write bytes into the raw TCP socket and get plaintext out.
>
> The point is to use AES for non-TLS protocols.
>
> On 6/25/23 14:15, Eric Rescorla wrote:
>
> I'm not aware of any. Why would you want to do this? Most such libraries I
> am aware of expose low-level primitives or are built on libraries which do.
>
> -Ekr
>
>
> On Sun, Jun 25, 2023 at 6:28 AM Soni L.  wrote:
>
>> Has anyone done any work towards tricking a TLS library into providing
>> cryptographic primitives? We know of similar work with regards to
>> javacard https://arxiv.org/abs/1810.01662 but not sure if it can be
>> applied to TLS.
>>
>> ___
>> 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] Tricking TLS library into crypto primitives library

[Eric Rescorla]

I'm not aware of any. Why would you want to do this? Most such libraries I
am aware of expose low-level primitives or are built on libraries which do.

-Ekr


On Sun, Jun 25, 2023 at 6:28 AM Soni L.  wrote:

> Has anyone done any work towards tricking a TLS library into providing
> cryptographic primitives? We know of similar work with regards to
> javacard https://arxiv.org/abs/1810.01662 but not sure if it can be
> applied to TLS.
>
> ___
> 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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Eric Rescorla]

On Mon, May 22, 2023 at 1:09 PM Rob Sayre  wrote:

> On Mon, May 22, 2023 at 12:59 PM Christopher Wood 
> wrote:
>
>> We trust the editors will faithfully enact all editorial changes they
>> agree with as the document moves forward in the process. If there were
>> non-editorial comments that we overlooked, could you please resurface them?
>>
>
> Hi,
>
> I made these comments about 1.5 months ago, so I hope it doesn't seem like
> I'm requesting a particularly quick turnaround.
>

Yes, this is my mistake. I just went through the Github issues and forgot
to deal
with this e-mail. I will create a PR for these.


> There were a couple obvious corrections EKR agreed with, but aren't done.
> These should be fixed before IETF Last Call.
>
> The one real problem (imho) with the document is nested MUST requirements:
> https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/
>
> EKR called this "guidance", but RFC 2119 says MUST is "an absolute
> requirement". The document needs to use the 2119 requirements language
> correctly. I understand the goal, which is to preserve wire-format
> compatibility in older TLS versions, even though they have security flaws.
>

As you indicate, the context here is that RFC 8996 forbids TLS < 1.2, but
we know people might ignore that and thus this text is intended to provide
requirements for people who do so. It's an inherently contradictory
situation,
but also the one we find ourselves in.

With that in mind, you seem to be making three points:

>   Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>   versions below 1.2; implementations which do not follow that guidance
>   MUST behave as described above.

Your complaint seems to boil down to the word "guidance", but the word
used there doesn't have normative force, so I think this is an
editorial issue.

I agree we should also cite E.5, and I can cite that in my PR.


Appendix E.5:
> >   The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
> >   and TLS 1.1 [RFC4346] are considered insufficient for the reasons
> >   enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT
> >  be negotiated for any reason.

> Here, I would end with "...for any reason in applications that require a
> secure channel."

I don't think that this is a good change. 8996 just flat out prohibits
them and so we should match that.

>
> >   Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
> > HELLO.  Implementations MUST NOT negotiate TLS 1.3 or later using an
> > SSL version 2.0 compatible CLIENT-HELLO.  Implementations are NOT
> >  RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
> >  order to negotiate older versions of TLS.
>
> Without the little trailing text I added above, this seems a little
> contradictory. The thinking here is the document says this is NOT
> RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS
> 1.2 here.

I don't see the problem here. You MUST NOT negotiate TLS < 1.2 and you
are NOT RECOMMENDED to use  the SSLv2 CH to negotiate TLS 1.2.

Perhaps your objection is to the use of the plural "older versions"
but again, we know that some people will ignore the E.5 requirement
and the point here is that even if they do so, they should still not
do this.

With all that said, if there is WG consensus to make these changes,
I'll of course do so. Deferring to the chairs on how to proceed.


-Ekr



-Ekr








___
> 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] [UNVERIFIED SENDER] Re: Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Eric Rescorla]

I agree with Ilari about the size of the registry. OTOH, I think it would
be good
to avoid confusion by creating a large number of code points which we know
will be abandoned soonish.

-Ekr


On Thu, May 11, 2023 at 11:19 PM Ilari Liusvaara 
wrote:

> On Thu, May 11, 2023 at 02:44:18PM +, Kampanakis, Panos wrote:
> > ACK, thx all. So we should refrain from defining such “point-in-time”
> > codepoints for other needed long-term algorithm combinations to not
> > waste registry space. Only absolutely necessary codepoints should be
> > registered.
>
> That registry has >64,000 free codepoints. I don't see there being
> anywhere close enough individual registrations to fill that up, no
> matter how loose the criteria are.
>
> However, with post-quantum, there is another reason to be careful:
> The shares are so large that the client effecively only has one shot.
>
>
> Some sort of systematic registrations reseving large chunks of space
> is the only way I can foresee the registry being seriously depleted.
> In contect of TLS groups, No such registrations exist currently, nor
> have I seen proposals for such thing.
>
>
>
>
> -Ilari
>
> ___
> 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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Eric Rescorla]

On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara 
wrote:

> On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> > On the subject of clarification, the update also needs to explain why
> PSK is
> > split across two separate extensions, psk_key_exchange_modes and
> > pre_shared_key, with complex and awkward reconciliation rules between
> then,
> > and why the PSK has to be the last extension in the client hello.  I
> can't see
> > any reason for either of those two, which in particular for the latter
> one
> > means why would an implementation follow that apparently pointless
> > requirement?  Is this codifying someone's implementation bug?  Do demons
> fly
> > out of your nose if it's not the last extension?
>
> For the first, I actually asked that very question during TLS 1.3
> development. Psk_key_exchange_modes can appear without pre_shared_key.
>

Yes. This is what happens in a non-resumption handshake, so that the client
can
advertise what it supports.


As for the second, the present method of computing binders (message
> truncation) requires pre_shared_key to be the last extension. While
> it would be possible to design ways of computing binders without such
> requirement, those methods would seem to be much more complicated.
>

Correct. The idea is that the binder is computed on a prefix of the CH, as
indicated
in S 4.2.11.2.

-Ekr


>
>
>
> -Ilari
>
> ___
> 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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Eric Rescorla]

On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre  wrote:

> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla  wrote:
>
>> Thanks for your feedback. Most of these are editorial comments and
>> so I think they're my decision as editor about which ones to take
>> absent some instruction from the chairs.
>>
>
> I agree concerning most of them. One just finds nitpicks if you read the
> whole thing carefully.
>
> The one thing I think is really substantive is the deprecation of TLS 1.0
> / 1.1, since you have a strange nesting of MUSTs.
>
> I think a descriptive "NOT RECOMMENDED" approach would be better here.
> Then, describe that servers might choose to accept 1.0/1.1 if they don't
> actually care whether the traffic is secure. This is a very common pattern.
> I found a survey that showed popular public sites were likely to accept
> almost anything (SSL3, unencrypted traffic, etc).*
>

I don't see how we can use NOT RECOMMENDED here, because we already have
an RFC which prohibits the use of TLS 1.0 and TLS 1.1 and we're not
contradicting
that. The purpose of the text you highlight is to address people who are
nonconformant
with that RFC.

-Ekr




>
> I think this approach is more accurate, but also more critical in terms of
> security than what you have now.
>
> thanks,
> Rob
>
> *
> "In fact, the top 100 sites were more likely to still support SSL 3, TLS
> 1.0, and TLS 1.1 than servers with much less traffic."
> <
> https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report
> >
>
>
>
>> On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:
>>
>>> Hi,
>>>
>>> I'm still not sure about the list/vector rename. Aside from that, here's
>>> what I found:
>>>
>>> > It tightens some requirements and contains
>>> > updated text in areas which were found to be unclear as well as other
>>> > editorial improvements.
>>>
>>> "It contains clarifications and tightened requirements." [let's assume
>>> some things were unclear and that editorial improvements are clarifications]
>>>
>>
>> Not all editorial improvements are clarifications.
>>
>>
>>>
>>> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
>>> [RFC8996].
>>>
>>> I know what's meant here, but deprecated does not mean forbidden. I
>>> think you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
>>> reason for that. [but keep reading]
>>>
>>
>> This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
>> and TLS 1.1" so I think this
>> is fine.
>>
>>
>>
>>> > The protocol does not provide any forward secrecy guarantees for this
>>> data.
>>> > The server's behavior determines what forward secrecy
>>> > guarantees, if any, apply (see Section 8.1). This behavior is
>>> > not communicated to the client as part of the protocol.
>>> > Therefore, absent out-of-band knowledge of the server's behavior,
>>> > the client should assume that this data is not forward secret.
>>>
>>> Here, you use the term "out-of-band", but the PSK text replaced
>>> "out-of-band" with "external[ly]". I can't tell whether this usage is
>>> intentional.
>>>
>>
>> It is. The PSKs here are resumption PSKs. They're not external. The out
>> of band in
>> question is knowledge about the server behavior.
>>
>>
>>
>>>
>>> > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
>>> > 1.3 and receives a ClientHello at any other time, it MUST terminate
>>>
>>> "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
>>> receives a ClientHello at any other time, it MUST terminate..."
>>>
>>> [No starting sentences with "Because"]
>>>
>>
>> I believe this is editor discretion.
>>
>>
>>>
>>> > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>>> > versions below 1.2; implementations which do not follow that guidance
>>> > MUST behave as described above.
>>>
>>> I think this makes my "NOT RECOMMENDED" suggestion above correct. A
>>> forbidden "MUST NOT" wouldn't need this text.
>>>
>>
>> I don't understand this argument. The point of this text is that people
>> are forbidden
>> to do previous versions by 8996, but we know som

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Eric Rescorla]

This was discussed extensively when 8446 was published and there wasn't
consensus
to make such a change. If the chairs want to re-open this issue, please
weigh in.

-Ekr


On Tue, Apr 4, 2023 at 7:32 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it looks good” response.
>
> I looked at the diff between 8446bis-07 and 8446 and it seems
> fine to me. My only comment is that C.4 says one "SHOULD NOT
> reuse a key share" - I'd be happier if that was a "MUST NOT"
> but understand if we stick with SHOULD NOT. If there were a
> good reference showing that it's quite feasible to never
> deliberately re-use a key share, even at scale, that'd be a fine
> addition. (I don't have such a reference to offer,
> sorry;-)
>
> Cheers,
> S.
> ___
> 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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Eric Rescorla]

Thanks for your feedback. Most of these are editorial comments and
so I think they're my decision as editor about which ones to take
absent some instruction from the chairs.

On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:

> Hi,
>
> I'm still not sure about the list/vector rename. Aside from that, here's
> what I found:
>
> > It tightens some requirements and contains
> > updated text in areas which were found to be unclear as well as other
> > editorial improvements.
>
> "It contains clarifications and tightened requirements." [let's assume
> some things were unclear and that editorial improvements are clarifications]
>

Not all editorial improvements are clarifications.


>
> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
> [RFC8996].
>
> I know what's meant here, but deprecated does not mean forbidden. I think
> you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
> reason for that. [but keep reading]
>

This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
and TLS 1.1" so I think this
is fine.



> > The protocol does not provide any forward secrecy guarantees for this
> data.
> > The server's behavior determines what forward secrecy
> > guarantees, if any, apply (see Section 8.1). This behavior is
> > not communicated to the client as part of the protocol.
> > Therefore, absent out-of-band knowledge of the server's behavior,
> > the client should assume that this data is not forward secret.
>
> Here, you use the term "out-of-band", but the PSK text replaced
> "out-of-band" with "external[ly]". I can't tell whether this usage is
> intentional.
>

It is. The PSKs here are resumption PSKs. They're not external. The out of
band in
question is knowledge about the server behavior.



>
> > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
> > 1.3 and receives a ClientHello at any other time, it MUST terminate
>
> "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
> receives a ClientHello at any other time, it MUST terminate..."
>
> [No starting sentences with "Because"]
>

I believe this is editor discretion.


>
> > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
> > versions below 1.2; implementations which do not follow that guidance
> > MUST behave as described above.
>
> I think this makes my "NOT RECOMMENDED" suggestion above correct. A
> forbidden "MUST NOT" wouldn't need this text.
>

I don't understand this argument. The point of this text is that people are
forbidden
to do previous versions by 8996, but we know some people won't so this is
backup guidance. I think this is fine.




>
> > Unless otherwise specified, trailing data is forbidden.
> > That is, senders MUST NOT include data after the structure in the
> > "extension_data" field.
>
> This doesn't seem like "MUST NOT", since it could be "otherwise
> specified". I think there needs to be a harsher choice made here, or just
> leave it out.
>

This is actually fairly standard language.



> > When processing an extension, receivers MUST
> > abort the handshake with a "decode_error" alert if there is data left
> > over after parsing the structure. This does not apply if the
> > receiver does not implement or is configured to ignore an extension.
>
> Again, doesn't seem like a "MUST". But the following text says "This does
> not apply", without clarifying what "this" is.
>

I don't follow your argument here either. It's a MUST for any extension you
understand.
Obviously, if you don't understand it, you can't comply with this. I'll
attempt to clarify.


> > After checking ServerHello.random to determine if the server
> > handshake message is a ServerHello or HelloRetryRequest, clients MUST
> > check for this extension prior to processing the rest of the
> > ServerHello.  This will require clients to parse the ServerHello in ...
>
> Another "this". Here, I think the text means "This requirement...", but
> usually a rewrite can fix these ambiguities.
>

I don't think this one is unclear.


> > In the absence of some other specification to the
> > contrary, servers which are authenticating with an external PSK MUST
> > NOT send the CertificateRequest message either in the main handshake
> > or request post-handshake authentication.  [RFC8773] provides an
> > extension to permit this, but has not received the level of analysis
> > as this specification.
>
> Another one of these "In the absence of..." paragraphs. Maybe these are
> intentional? They still sound really redundant to me.
>

They're intentional because we know there is actually such an RFC, but you
have to
actually use it.


> > With a 128-bit key as in AES-128, rekeying 2^64 times has a high
> > probability of key reuse within a given connection.  Note that even...
>
> It's almost always possible to drop "Note that..."
>

It is possible, but I prefer to leave it as-is.


> The rest of this paragraph is really heavy on em dashes, and needs to be
> rewritten. Some of them 

Re: [TLS] TLS 1.2 deprecation and RFC 7627

[Eric Rescorla]

On Sat, Apr 1, 2023 at 12:15 PM Dmitry Belyavsky  wrote:

> Dear Martin,
>
> On Sat, 1 Apr 2023, 19:36 Martin Thomson,  wrote:
>
>> On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote:
>> > Are the things like national-wide standards considered as new features
>> > (until they don't pretend to be Internet-wide standards)?
>>
>> I would not expect the IETF to be specifying national standards (that's
>> an obvious contradiction anyway).
>>
>> It is also unnecessary.  The registration policies for TLS registries
>> allow people to register extensions without IETF involvement (unless you
>> consider IETF-appointed experts), so they should feel free to extend in any
>> way that makes them happy.
>>
>
> Right, but national standards often go through Independent stream
>

Yes they do -- though it seems like it would be easier all around if they
just registered on the basis of I-Ds. In any case, they will be able to
continue to do so under the proposed course of action.

-Ekr

___
> 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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Eric Rescorla]

I support this proposal.



On Tue, Mar 28, 2023 at 6:49 PM Christopher Wood 
wrote:

> As discussed during yesterday's meeting, we would like to assess consensus
> for moving draft-ietf-tls-hybrid-design forward with the following strategy
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

[Eric Rescorla]

On Mon, Mar 27, 2023 at 2:28 AM Salz, Rich  wrote:

>
>
> I would prefer to have any substantive changes in 8446-bis and the policy
> changes in 8447-bis
>
>
>
> Now I’m more confused, since I consider policy changes substantive
> things.  And I’m not sure what policy is.
>

Looking at 8446 and 8447:

- 8446 registered new code points
- 8447 (mostly) changed the policies for issuance of new code points

I'm suggesting that we maintain that separation for the -bis documents.

-Ekr


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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

[Eric Rescorla]

I would prefer to have any substantive changes in 8446-bis and the policy
changes in 8447-bis

-Ekr


On Mon, Mar 27, 2023 at 2:10 AM Salz, Rich  wrote:

>
> > Title : IANA Registry Updates for TLS and DTLS
> > Authors : Joe Salowey
> > Sean Turner
> > Filename : draft-ietf-tls-rfc8447bis-04.txt
> ...
> > This document updates the changes to TLS and DTLS IANA registries
> > made in RFC 8447. It adds a new value "D" for discouraged to the
> > recommended column of the selected TLS registries.
>
> Rfc84460bis makes some changes to the registries. Does it make sense to
> merge those changes into this document so that we have fewer overlapping
> changes?  (The items in Section 11.1 defnitely, and maybe some of the
> changes in Section 11)
>
> ___
> 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] draft-ietf-tls-rfc8446bis-07

[Eric Rescorla]

I have just posted draft-ietf-tls-rfc8446bis-07

This incorporates the following changes:

- Updated text about differences from RFC 8446.
- Clarify which parts of IANA considerations are new to this document.
- Upgrade the requirement to initiate key update before exceeding
  key usage limits to MUST (PR 1301)
- Add some text around use of the same cert for client and server (PR 1300)

This now closes all the open issues, so I believe we are
ready for WGLC.

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

Re: [TLS] Proposal to Enhance TLS Mutual Authentication Security

[Eric Rescorla]

AS Viktor noted in a separate e-mail TLS 1.3 already encrypts the client
certificate.

-Ekr


On Sun, Mar 26, 2023 at 4:00 PM Yannick LaRue  wrote:

> Dear TLS Working Group,
>
>
>
> I am writing to propose a new method for enhancing the security of mutual
> authentication in TLS. The current TLS protocol requires the exchange of
> client and server certificates in cleartext during the initial handshake,
> which exposes sensitive client information to potential man-in-the-middle
> attacks. In order to address this vulnerability, I propose implementing a
> second handshake that requests the client certificate only after the secure
> channel has been established.
>
>
>
> Under this method, if the client chooses to engage in mutual
> authentication and sends their certificate, the security can be
> renegotiated using the client certificate instead of the server
> certificate. This would provide an additional layer of security, as any
> attacker intercepting the exchange would not be able to discern how the new
> secure channel was negotiated.
>
>
>
> I believe this proposed method would be compatible with TLS 1.4, without
> disrupting backward compatibility with earlier versions such as TLS 1.3. As
> mutual authentication implies a desire for stronger security, any potential
> increase in overhead or processing required by this method would likely be
> acceptable to users.
>
>
>
> Moreover, this proposal would also be in line with GDPR requirements, as
> it would reduce the amount of client information exchanged during the
> initial handshake and offer more control over personal data.
>
>
>
> Thank you for considering my proposal. I would be happy to discuss this
> idea further or provide additional details as needed.
>
>
>
> Best regards,
>
>
>
> Yannick LaRue
> ___
> 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] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes

[Eric Rescorla]

Hans Petter,

Before I address your technical points, I would observe that your
tone here isn't ideal for getting people excited about your ideas.
If you think there's something that people don't understand, then
by all means explain it, but telling people that they have a "total lack
of kernel-side insight" or that their "technology and ideas will be totally
left behind" doesn't really foster good will.


On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky 
wrote:

> On 3/24/23 23:59, Watson Ladd wrote:
> > On Fri, Mar 24, 2023 at 2:09 AM Hans Petter Selasky 
> wrote:
> > 
> >> OK
> >>
> >> I see where you guys are falling off.
> >>
> >> Professionals already encrypt the video files served using
> >> (confidentiality, integrity and authenticity).
> >>
> >> These files are also served using HTTP, unencrypted, but then people can
> >> easily compare the contents to figure out what is being watched, even if
> >> encrypted.
> >>
> >> The transport layer TCP/IP/TLS does not need the authenticity part in
> >> this case, because the files served are already fully encrypted, if that
> >> makes sense.
> >
> > The file is not what is transported over TLS connection. The HTTP
> > response is transported. That response includes things like headers
> > whose manipulation could have negative effects on security: e.g.
> > setting cookies.
> >
> > There's also a fundamental architectural issue: the HTTP server does
> > not know what file will be requested when negotiating the TLS
> > ciphersuite, and the TLS connection is used across multiple HTTP
> > requests. That makes accepting a different ciphersuite for some
> > requests extremely difficult to actually implement.
> >
> > Does the underlying encryption ensure authenticity?
> >
> > Lastly I'm not sure I understand what the performance issue is with
> > the offloading. I think what you're saying is you need more memory to
> > track the encrypted and authenticated segments on retransmission than
> > just knowing the offsets, but I think that would be a problem with any
> > sort of TLS record packing that has different boundaries from the TCP
> > segmentation. If you line them up, then the MAC tag isn't any more
> > difficult.  It also isn't the case that AES-GCM can ignore the
> > segmentation even without the MAC: the nonce is xored with the
> > write_iv, and then the nonce is combined with a counter starting at 1
> > that occupies the low 32 bits to get the keystream.
> >
> > Are you proposing just using AES-CTR ignoring the record segmentation
> entirely?
>
> Hi Watson Ladd,
>
> I had a longer conversation on Whatsapp with another guy from the IETF
> list.
>
> I see there is some knowledge gap between you guys sitting in the IETF
> and me in the implementation department sort of.
>

> There are basically three ways to do TLS encryption:
>
> 1) OpenSSL (or the alike in user-space)
> 2) AES CPU instructions in the kernel (all done in kernel space)
> 3) The network card does AES encryption and decryption
>
> In case 1) and 2) there is no problem.
>
> In case 3) there is also no problem, until you have a packet loss and
> retransmission. The NIC cannot remember previously computed SHA-256 and
> AES-CTR data, and so if you need to retransmit only the SHA-256 hash
> data, then all of the TLS record, usually up to 16 kilobytes, needs to
> be "dumped" (not transmitted) via the crypto engine in the NIC, to
> re-compute the SHA-256 hash data.
>

Several points here:
1. Can you explain where SHA-256 comes in here, as it's not used with
AES-GCM? I'm not following the problematic scenario.

2. I understand that you say that there is a problem with packet loss and
retransmission, but on correctly functioning networks, packet loss rates
should be quite low (<5%), in which case the overhead of just treating
the retransmission as if it were a fresh send. I agree that it's not ideal,
but won't the overhead just be the same as if you were sending a few
percent more data.

3. Being able to retransmit pre-encrypted TLS records is a feature of
TLS over TCP, but not of QUIC, where retransmissions entail a fresh
encryption. As more traffic moves to H3, especially for high-speed
applications, it seems like any optimization we do here would be
increasingly
less useful.

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

[TLS] draft-ietf-tls-rfc8446bis-06 posted

[Eric Rescorla]

Hi,

I just submitted draft-ietf-tls-rfc8446bis-06.

Here is a summary of the Changes since -05. I believe the following
changes are largely uncontroversial and were widely reviewed.

   *  Advice on key deletion (PR 1282)

   *  Clarify what unsolicited extensions means (PR 1275)

   *  close_notify should be warning (PR 1290)


The following got somewhat less review, but I merged in order to get
this in before the deadline. If people feel strongly that I got it
wrong, then please speak up. I also closed a few PRs on these
same topics in favor of the PRs below.

   *  Discuss the privacy implications of external key reuse (Issue
  1287)

   *  Clarify that you need to ignore NST if you don't do resumption
  (Issue 1280)

   *  Port in text on key update limits from RFC 9147 (Issue 1257)

   *  Reference RFC 8773 (PR 1296)

   *  Add some more information about application bindings and cite
  6125-bis (PR 1297)


There is one remaining issue, which I was undecided on how to handle:

   Security considerations of using same cert for TLS client and server
   https://github.com/tlswg/tls13-spec/issues/1291

My sense is that this has seen less analysis than other properties
of TLS 1.3 and we should say that, but I'm open to other approaches.
I don't think the MAY in PR 1292 is sufficient guidance.


Aside from this issue, I believe that this document is ready for
WGLC. If we come to an agreement on how to handle Issue 1921 I
can submit a new draft immediately, or we can treat it as
a LC comment.

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Eric Rescorla]

Nimrod,

Thanks for bringing this up. I don't think we really have had much of a
discussion.

I *do* think we should be thinking about deprecating TLS 1.2 at some point,
not so much because
it is bad (though of course we believe TLS 1.3 is better)  but because it's
better to just have
one thing that we work on and not have to reason about/work on TLS 1.2. And
of course, we really
don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.

I don't have strong feelings about the timeline.

-Ekr




On Fri, Mar 3, 2023 at 10:18 AM Nimrod Aviram 
wrote:

> Hi Everyone,
>
> We’ve recently had a brief side discussion around the issue of letting
> vendors (or operators) know when something is expected to be deprecated:
> https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/
>
> Currently, there is no expected deprecation timeline for any specific
> primitive or protocol version. As one example, it seems like we plan to
> deprecate RSA key exchange in TLS 1.2 soon (as part of
> draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not
> explicitly communicate this to vendors, and it seems like vendors either
> have to follow the mailing list and deduce the likelihood of an upcoming
> deprecation, or face a deprecation RFC at some random point in time (from
> their point of view).
>
> And whatever the specifics of RSA key exchange deprecation, this will
> likely not be the last time we deprecate something :-)
>
> Specifically, we will have to decide when/if to deprecate version 1.2 of
> TLS within, say, the next 20 years.
>
> One possible solution is to publish “expected deprecation timeline”
> documents:
> Let’s fix some timeframe which “is enough for everyone to upgrade at least
> once” (famous last words, I know). I think of this timeframe as 3 or 5
> years, but it could as well be 8 or 10 years, and this solution would still
> be viable; let’s denote the number of years as X. So, an “expected
> deprecation timeline” document could specify that within X years,
> implementations MUST support TLS 1.3, and within 2X years, implementations
> MUST NOT support TLS 1.2. (If X=8 years, then we specify that by 2031
> implementations MUST support TLS 1.3, and by 2039 implementations MUST NOT
> support TLS 1.2.) This would clarify the WG’s expectations to vendors, and
> would save the WG valuable time discussing whether enough implementations
> in the field support the new protocol/primitive.
>
> Is there interest here in such a solution?
>
> Credit where it’s due: This is based on an idea I heard from Dan Bernstein
> - thanks Dan.
>
> Best,
> Nimrod
>
> ___
> 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] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

[Eric Rescorla]

On Fri, Mar 3, 2023 at 9:21 AM Nimrod Aviram 
wrote:

> Hi Eric and Everyone, draft coauthor here.
>
> Appendix C lists "DHE Cipher Suites Refered to by This Document", not ones
> which are deprecated.
>
The intention of the current text is to permit fully ephemeral DHE over a
> finite field (FFDHE) with sufficient group size.
>

That's what I got from the title of Appendix CA, but then what does this
text
mean:

"All the cipher suites that do not meet the above requirements are
 listed in the table in Appendix C."

Because, as you say, some of the suites in C meet this requirement.



>
> However, we also have an unresolved consensus call regarding whether/to
> what extent to permit FFDHE when this document (hopefully) becomes an
> official RFC:
> https://mailarchive.ietf.org/arch/msg/tls/iZGV0kKHfbV5MrO-owB8mFwfffw/
> so at any rate, the current text around FFDHE is mostly a placeholder.
> I do hope to present at the upcoming WG meeting and resolve this issue,
> which should be the last one (famous last words, I know).
>
> Happy to answer further questions, or generally get a discussion going on
> here before the meeting.
>

OK, so we don't need to spend too much time on this, but I'd still like to
understand
the intent :)

-Ekr


>
> best,
> Nimrod
>
>
>
>
> On Thu, 2 Mar 2023 at 23:19, Eric Rescorla  wrote:
>
>> Hi folks,
>>
>> I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
>> and the combination of Section 3 and Appendix C is confusing
>> to me.
>>
>> Specifically, the text says:
>>
>>Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
>>TLS 1.2 connections under the following conditions:
>>
>>1.  Clients and servers MUST NOT reuse ephemeral DHE public keys
>>across TLS connections for all existing (and future) TLS
>>versions.  Doing so invalidates forward secrecy properties of
>>these connections.  For DHE, such reuse may also lead to
>>vulnerabilities such as those used in the [Raccoon] attack.  See
>>Section 6 for related discussion.
>>
>>2.  The group size is at least 2048 bits.
>>
>>...
>>
>>All the cipher suites that do not meet the above requirements are
>>listed in the table in Appendix C.
>>
>>
>> And then Appendix C lists, for instance:
>>
>>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>>
>> Which as I understand it, can be used with the above requirements
>> as long as you use a suitable group, so this makes me think maybe
>> I don't understand the text. What cipher suites is this intended
>> to permit in TLS 1.2?
>>
>> -Ekr
>>
>>
>>
>> ___
>> 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] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

[Eric Rescorla]

Hi folks,

I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
and the combination of Section 3 and Appendix C is confusing
to me.

Specifically, the text says:

   Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
   TLS 1.2 connections under the following conditions:

   1.  Clients and servers MUST NOT reuse ephemeral DHE public keys
   across TLS connections for all existing (and future) TLS
   versions.  Doing so invalidates forward secrecy properties of
   these connections.  For DHE, such reuse may also lead to
   vulnerabilities such as those used in the [Raccoon] attack.  See
   Section 6 for related discussion.

   2.  The group size is at least 2048 bits.

   ...

   All the cipher suites that do not meet the above requirements are
   listed in the table in Appendix C.


And then Appendix C lists, for instance:

   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Which as I understand it, can be used with the above requirements
as long as you use a suitable group, so this makes me think maybe
I don't understand the text. What cipher suites is this intended
to permit in TLS 1.2?

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

Re: [TLS] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Fri, Jan 6, 2023 at 11:43 PM Achim Kraus  wrote:

>
>  > 2. A single server serving multiple clients, where the clients share an
>  > address.
>
> Not sure, if "address" is just the ip-address or the ip-address and
> service port. For the first it works in DTLS 1.2 CID, if the clients
> have different service ports.


You don't need CID for demultiplexing in this case.


For the second it may depend on the
> implementation. My implementations of DTLS 1.2 CID don't support that.
>

OK. Well, I believe that CID *can* handle this. Do you think otherwise?



>  > 3. A single endpoint acting as both client and server on the same
> address.
>
> See the DTLS 1.2 role exchange discussion in LwM2M.
>

I don't follow LwM2M, but DTLS-SRTP already handles this case.  See:
https://www.rfc-editor.org/rfc/rfc5763#section-5

If you're aware of cases where this design does not correctly handle
the situation, please surface them...

-Ekr


> Am 06.01.23 um 23:17 schrieb Eric Rescorla:
> >
> >
> > On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak  > <mailto:xpeperm...@gmail.com>> wrote:
> >
> >
> >> On 6 Jan 2023, at 18:39, Eric Rescorla  >> <mailto:e...@rtfm.com>> wrote:
> >>
> >>
> >>
> >> On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak
> >> mailto:xpeperm...@gmail.com>> wrote:
> >>
> >> > If I understand correctly, the issue here is a difference
> >> between DTLS and
> >> > "Datagram cTLS".  In DTLS, the syntax allows a client to
> >> parse handshake
> >> > messages from the server and discover that the message is
> >> actually a
> >> > ClientHello.  I don't know that this is a good idea, or
> actually
> >> > implemented anywhere, or even formally "allowed", but it's
> >> at least
> >> > syntactically possible.
> >>
> >> Yes.
> >>
> >> > In Datagram cTLS (as of -07), this is not possible.  The
> >> parsing of
> >> > handshake messages depends on prior knowledge of who is the
> >> client and who
> >> > is the server.  This is because CTLSServerPlaintext and
> >> CTLSClientPlaintext
> >> > are different structs, but they use the same ContentType.
> >>
> >> OK, "prior knowledge" explains everything :). I assumed all
> >> structures should be parsed as unique objects.
> >>
> >> RFC9146 and RFC9147 somehow confused me and made me think that
> >> by using CIDs it's allowed to reuse sockets A and B and then
> >> handle multiple connections through a single path. In that
> >> case you would have clients and servers on both sides. Inputs
> >> from this thread suggest that CIDs are meant for "NAT
> >> rebinding" purpuse only.
> >>
> >>
> >> Hmm, no, I don't think that's quite true. A server can serve
> >> multiple clients on the same 4-tuple using the CID. It's just that
> >> it will not generally act as a client.
> >
> > For sure, a server can serve multiple clients on the same address
> > :). What I meant is that, isolated to a single path, an endpoint (A
> > or B) should only be a server or a client, not both at the same
> > time. So a single "ip:port" is not supposed to “initiate”/"run"
> > multiple isolated servers and clients at the same time.
> >
> >
> > There are three things going on here, not two.
> >
> > 1. A single server serving multiple clients, where the clients have
> > different addresses.
> > 2. A single server serving multiple clients, where the clients share an
> > address.
> > 3. A single endpoint acting as both client and server on the same
> address.
> >
> > DTLS allows (1) by default (2) with CID, and not (3).
> >
> > -Ekr
> >
> >
> >> -Ekr
> >>
> >>
> >> -Kristijan
> >
> >
> > ___
> > 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] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak 
wrote:

>
> On 6 Jan 2023, at 18:39, Eric Rescorla  wrote:
>
>
>
> On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak 
> wrote:
>
>> > If I understand correctly, the issue here is a difference between DTLS
>> and
>> > "Datagram cTLS".  In DTLS, the syntax allows a client to parse handshake
>> > messages from the server and discover that the message is actually a
>> > ClientHello.  I don't know that this is a good idea, or actually
>> > implemented anywhere, or even formally "allowed", but it's at least
>> > syntactically possible.
>>
>> Yes.
>>
>> > In Datagram cTLS (as of -07), this is not possible.  The parsing of
>> > handshake messages depends on prior knowledge of who is the client and
>> who
>> > is the server.  This is because CTLSServerPlaintext and
>> CTLSClientPlaintext
>> > are different structs, but they use the same ContentType.
>>
>> OK, "prior knowledge" explains everything :). I assumed all structures
>> should be parsed as unique objects.
>>
>> RFC9146 and RFC9147 somehow confused me and made me think that by using
>> CIDs it's allowed to reuse sockets A and B and then handle multiple
>> connections through a single path. In that case you would have clients and
>> servers on both sides. Inputs from this thread suggest that CIDs are meant
>> for "NAT rebinding" purpuse only.
>>
>
> Hmm, no, I don't think that's quite true. A server can serve multiple
> clients on the same 4-tuple using the CID. It's just that it will not
> generally act as a client.
>
>
> For sure, a server can serve multiple clients on the same address :). What
> I meant is that, isolated to a single path, an endpoint (A or B) should
> only be a server or a client, not both at the same time. So a single
> "ip:port" is not supposed to “initiate”/"run" multiple isolated servers and
> clients at the same time.
>

There are three things going on here, not two.

1. A single server serving multiple clients, where the clients have
different addresses.
2. A single server serving multiple clients, where the clients share an
address.
3. A single endpoint acting as both client and server on the same address.

DTLS allows (1) by default (2) with CID, and not (3).

-Ekr


> -Ekr
>
>
>> -Kristijan
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak 
wrote:

> > If I understand correctly, the issue here is a difference between DTLS
> and
> > "Datagram cTLS".  In DTLS, the syntax allows a client to parse handshake
> > messages from the server and discover that the message is actually a
> > ClientHello.  I don't know that this is a good idea, or actually
> > implemented anywhere, or even formally "allowed", but it's at least
> > syntactically possible.
>
> Yes.
>
> > In Datagram cTLS (as of -07), this is not possible.  The parsing of
> > handshake messages depends on prior knowledge of who is the client and
> who
> > is the server.  This is because CTLSServerPlaintext and
> CTLSClientPlaintext
> > are different structs, but they use the same ContentType.
>
> OK, "prior knowledge" explains everything :). I assumed all structures
> should be parsed as unique objects.
>
> RFC9146 and RFC9147 somehow confused me and made me think that by using
> CIDs it's allowed to reuse sockets A and B and then handle multiple
> connections through a single path. In that case you would have clients and
> servers on both sides. Inputs from this thread suggest that CIDs are meant
> for "NAT rebinding" purpuse only.
>

Hmm, no, I don't think that's quite true. A server can serve multiple
clients on the same 4-tuple using the CID. It's just that it will not
generally act as a client.

-Ekr


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

Re: [TLS] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Thu, Jan 5, 2023 at 6:31 AM Ben Smyth  wrote:

> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak 
> wrote:
> > ...how will an endpoint correctly distinguish between multiple,
> CID-ext-based CTLSClientPlaintext requests and CTLSServerPlaintext
> responses when the same socket is used for client and server communication.
>
> On Wed, 4 Jan 2023 at 15:29, Ben Schwartz  40google@dmarc.ietf.org> wrote:
> > cases where (1) a single 5-tuple can be used for DTLS in both
> directions, (2) the parties have not already agreed who will be the client
> and who will be the server, and (3) there can be multiple handshakes in
> flight simultaneously.  In this case, a party who sends a ClientHello might
> receive a ServerHello, HRR, or a racing ClientHello in response.  This is
> not a use case I had thought about.  Is this considered a supported
> configuration for DTLS (with Connection IDs)?
>
> On Wed, 4 Jan 2023 at 17:10, Eric Rescorla  wrote:
> > When would this actually happen?
>
> Assuming this could happen, then the RFC should surely mention the
> possibility, and perhaps be reworked to avoid raising an error.
>

Perhaps?

This has been a feature of DTLS (and in fact TLS) since the very beginning
and I have not seen cause
significant confusion in the wild.

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

Re: [TLS] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Wed, Jan 4, 2023 at 12:02 PM Kristijan Sedlak 
wrote:

> Thank you both.
>
> I agree that a signaling server would be needed for a serious p2p network
> and I believe libraries such as libp2p include that plus all sorts of other
> mechanics.
>
> Since every RFC represents a beast itself, I try not to think much about
> all the machinery that usually comes in a box, but rather about a simpler
> product considering only the (TLS) specs that are really needed. A small
> change to the spec would allow for building a simpler p2p product with a
> small and simple code base.
>

But this P2P product will not be viable absent some kind of NAT traversal.


> In any case, I believe that protocols and related use cases, if possible,
> should not depend on some external logic. Another argument is that objects
> should always be deterministic since every IF sentence represents an
> additional hurdle.
>
> Let me know if my arguments convince you.
>

This does not actually convince me. Rather, I think TLS should be designed
to fit within the environment in which it will be deployed and not
duplicate that environment's functionality and in that environment it seems
to me that the roles are deterministic.

If you can point me to a real world environment where this kind of tie
breaker is needed, I might feel differently.

-Ekr


> K
>
> On 4 Jan 2023, at 19:06, Eric Rescorla  wrote:
>
>
>
> On Wed, Jan 4, 2023 at 8:34 AM Kristijan Sedlak 
> wrote:
>
>> Yes, I'm referring to P2P networks.
>>
>> Hum … let me try to explain. Imagine a group of computers discovering
>> each other through Kademilia or similar. Each endpoint is required to
>> connect to N remote nodes so it can then in theory access all parts of the
>> network. Each endpoint uses a single socket address, communicates over UDP,
>> and can accept connections or can initiate them.
>>
>
> In my experience this is not actually how these systems work. The reason
> is that those devices are
> usually end-user devices and are often behind NATs, so they need to use
> some protocol like
> ICE to do NAT traversal. Those protocols are able to establish who is who
> as part of the process.
> This is how WebRTC works, for instance.
>
> -Ekr
>
>
>
>> A socket can serve multiple virtualized clients thus DTLS CIDs are used.
>> Endpoints go live and then disappear - so you don't really know who's a
>> client and who's a server. In case a connection has already been
>> established by some initiator then you don't need to initiate a new
>> connection when "the algorithm" requires connection establishment.
>>
>> I hope the above makes sense.
>>
>
>
>
>> K
>>
>> On 4 Jan 2023, at 17:10, Eric Rescorla  wrote:
>>
>>
>>
>> On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz > 40google@dmarc.ietf.org> wrote:
>>
>>> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak 
>>> wrote:
>>>
>>>> Hey,
>>>>
>>>> The record layer of the cTLS skips the "profile_id" in the
>>>> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish
>>>> between multiple, CID-ext-based CTLSClientPlaintext requests and
>>>> CTLSServerPlaintext responses when the same socket is used for client and
>>>> server communication.
>>>
>>>
>>> It sounds like you are thinking about cases where (1) a single 5-tuple
>>> can be used for DTLS in both directions, (2) the parties have not already
>>> agreed who will be the client and who will be the server, and (3) there can
>>> be multiple handshakes in flight simultaneously.  In this case, a party who
>>> sends a ClientHello might receive a ServerHello, HRR, or a racing
>>> ClientHello in response.  This is not a use case I had thought about.  Is
>>> this considered a supported configuration for DTLS (with Connection IDs)?
>>>
>>
>> When would this actually happen? In my experience the only situation in
>> which there is ambiguity about who will be the client and the server are
>> p2p-style applications and those need ICE for NAT traversal, so you already
>> have a way of determining who is who.
>>
>> -Ekr
>>
>>
>>
>>
>>>
>>>
>>>> I believe there should be a different content_type for a request and
>>>> response or just a requirement that the response always has `profile_id=0`
>>>> or smth.
>>>
>>>
>>> If we decide this use case is in-scope, I would add a content_type to
>>> distinguish the roles.  I'm interested to hear if people feel this use case
>>> is in scope.
>>>
>>>
>>>> I hope I'm not reacting too fast and thus my writing makes sense.
>>>>
>>>> K
>>>>
>>>> ___
>>>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Wed, Jan 4, 2023 at 8:34 AM Kristijan Sedlak 
wrote:

> Yes, I'm referring to P2P networks.
>
> Hum … let me try to explain. Imagine a group of computers discovering each
> other through Kademilia or similar. Each endpoint is required to connect to
> N remote nodes so it can then in theory access all parts of the network.
> Each endpoint uses a single socket address, communicates over UDP, and can
> accept connections or can initiate them.
>

In my experience this is not actually how these systems work. The reason is
that those devices are
usually end-user devices and are often behind NATs, so they need to use
some protocol like
ICE to do NAT traversal. Those protocols are able to establish who is who
as part of the process.
This is how WebRTC works, for instance.

-Ekr



> A socket can serve multiple virtualized clients thus DTLS CIDs are used.
> Endpoints go live and then disappear - so you don't really know who's a
> client and who's a server. In case a connection has already been
> established by some initiator then you don't need to initiate a new
> connection when "the algorithm" requires connection establishment.
>
> I hope the above makes sense.
>



> K
>
> On 4 Jan 2023, at 17:10, Eric Rescorla  wrote:
>
>
>
> On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz  40google@dmarc.ietf.org> wrote:
>
>> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak 
>> wrote:
>>
>>> Hey,
>>>
>>> The record layer of the cTLS skips the "profile_id" in the
>>> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish
>>> between multiple, CID-ext-based CTLSClientPlaintext requests and
>>> CTLSServerPlaintext responses when the same socket is used for client and
>>> server communication.
>>
>>
>> It sounds like you are thinking about cases where (1) a single 5-tuple
>> can be used for DTLS in both directions, (2) the parties have not already
>> agreed who will be the client and who will be the server, and (3) there can
>> be multiple handshakes in flight simultaneously.  In this case, a party who
>> sends a ClientHello might receive a ServerHello, HRR, or a racing
>> ClientHello in response.  This is not a use case I had thought about.  Is
>> this considered a supported configuration for DTLS (with Connection IDs)?
>>
>
> When would this actually happen? In my experience the only situation in
> which there is ambiguity about who will be the client and the server are
> p2p-style applications and those need ICE for NAT traversal, so you already
> have a way of determining who is who.
>
> -Ekr
>
>
>
>
>>
>>
>>> I believe there should be a different content_type for a request and
>>> response or just a requirement that the response always has `profile_id=0`
>>> or smth.
>>
>>
>> If we decide this use case is in-scope, I would add a content_type to
>> distinguish the roles.  I'm interested to hear if people feel this use case
>> is in scope.
>>
>>
>>> I hope I'm not reacting too fast and thus my writing makes sense.
>>>
>>> K
>>>
>>> ___
>>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Profile ID in CTLSServerPlaintext

[Eric Rescorla]

On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz  wrote:

> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak 
> wrote:
>
>> Hey,
>>
>> The record layer of the cTLS skips the "profile_id" in the
>> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish
>> between multiple, CID-ext-based CTLSClientPlaintext requests and
>> CTLSServerPlaintext responses when the same socket is used for client and
>> server communication.
>
>
> It sounds like you are thinking about cases where (1) a single 5-tuple can
> be used for DTLS in both directions, (2) the parties have not already
> agreed who will be the client and who will be the server, and (3) there can
> be multiple handshakes in flight simultaneously.  In this case, a party who
> sends a ClientHello might receive a ServerHello, HRR, or a racing
> ClientHello in response.  This is not a use case I had thought about.  Is
> this considered a supported configuration for DTLS (with Connection IDs)?
>

When would this actually happen? In my experience the only situation in
which there is ambiguity about who will be the client and the server are
p2p-style applications and those need ICE for NAT traversal, so you already
have a way of determining who is who.

-Ekr




>
>
>> I believe there should be a different content_type for a request and
>> response or just a requirement that the response always has `profile_id=0`
>> or smth.
>
>
> If we decide this use case is in-scope, I would add a content_type to
> distinguish the roles.  I'm interested to hear if people feel this use case
> is in scope.
>
>
>> I hope I'm not reacting too fast and thus my writing makes sense.
>>
>> K
>>
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [arch-d] Question regarding Connection ID (CID) in DTLS /QUIC.

[Eric Rescorla]

This question should go to the TLS mailing list, not to
architecture-discuss. I have CCed that list.

On Fri, Dec 9, 2022 at 3:02 AM Kristijan Sedlak 
wrote:

> Hello, everyone.
>
> I'm scratching my head on RFC 9146 and wonder about the correct
> implementation strategy. Connection IDs in DTLS 1.3 are not mandatory and
> thus leave related challenges to the implementor.
>
> As I understand DTLS 1.3 allows endpoints to choose whether to support
> ConnectionId extension or not. If the sender includes ConnectionId
> extension in the ClientHello, the receiver knows that CIDs are supported
> and it can include its CID in the ServerHello, but if the receiver does not
> support the extension it will not include it in the ServerHello and the
> sender will get that info.
>
> What should we do if an endpoint features depend on CIDs but the targeting
> peer does not support the CID extension? Let's say that the sender will
> reuse the socket (ip:port) and serve multiple standalone "connections"
> through it (N ClientHello messages will start N connections over the same
> socket and the peer needs to use CIDs to distinguish between them) and thus
> require the remote endpoint to support CIDs? Should an endpoint (sender or
> receiver) that requires CIDs reply with unsupported extension alert?


If you need connection ids and the peer doesn't support them, you should
probably
terminate the connection with a "handshake_failure" alert. Alternately, you
could
only allow one connection at a time.

-Ekr
___
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] [Technical Errata Reported] RFC8446 (7250)

[Eric Rescorla]

On Mon, Nov 14, 2022 at 11:28 AM Alan DeKok  wrote:

> On Nov 14, 2022, at 1:09 PM, Eric Rescorla  wrote:
> >   I'd like to have a way to say "if you don't support session tickets,
> just ignore them".
> >
> > Again this text is not quite right because
>
>   I think you're talking at cross purposes to the problem I'm trying to
> describe.
>

Yes, I had thought you were talking about the server. I got confused
because your text said "extension" but NewSessionTicket is not an extension
but rather a handshake message. My mistake.



> Can you explain how you got into this posture? The only reason a client
> should be sending session tickets is if it received one
> > from the server.
>
>   The problem isn't that.  The problem is long before the client tries to
> reconnect.  The problem is the client, not the server.  The problem is that
> the initial connection to the server is never successful.  It has nothing
> to do with other uses of PSKs.  It has nothing to do with clients sending
> anything to the server.
>
>   The flow is this:
>
>  Client connects to server.
>
>  Client and server exchange TLS information.  They're both happy with
> everything.
>
>  Server eventually sends a session ticket to the client.
>

>  Client goes "OMFG" and hangs up.  No more TLS session.
>
>  Repeat ad nauseam until server administrator (a) forbids the use of
> TLS 1.3, or (b) forbids session tickets.
>
>
>   Windows 11 is doing this today with TLS-based EAP methods.  It's a
> disaster.
>

I agree that this is a defect.


  Again, from Section 4.6.1.:
>
>   The client MAY use this PSK for future handshakes by including the
>   ticket value in the "pre_shared_key" extension in its ClientHello
>
>   and by *implication* the client also does not need to use the session
> ticket.  It is free to use the session ticket, or to ignore it entirely.
>
>   What the client is *not* free to do is to treat the session ticket as a
> TLS connection failure.  This behavior can best be described as
> "surprising".
>

Yes, I agree with that. I would have thought this to be implicit in the
spec, but I have filed https://github.com/tlswg/tls13-spec/issues/1280 to
address it for 8446-bis.

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7250)

[Eric Rescorla]

On Mon, Nov 14, 2022 at 9:55 AM Alan DeKok  wrote:

> On Nov 14, 2022, at 12:43 PM, Eric Rescorla  wrote:
> > I don't believe this is correct.
>
>   I'd like to have a way to say "if you don't support session tickets,
> just ignore them".
>

Again this text is not quite right because it is possible to have PSKs that
are not session tickets, and you can't always tell whether a PSK is a
ticket or not.

  Right now, the observed behaviour is "we don't support session tickets,
> so we drop any TLS connection which uses them".
>

>   This literally has world-wide implications for WiFi network access
> today.  It is actively preventing the use of TLS 1.3.
>

Can you explain how you got into this posture? The only reason a client
should be sending session tickets is if it received one
from the server.


> I do think this document should make clear cases where you are supposed
> to ignore specific unknown values. I think it does that for this, but if
> you have other examples, please file an issue on RFC 8446-bis:
> https://github.com/tlswg/tls13-spec/
>
>   I can file an issue there.  But advice to "ignoring unknown values" is
> substantially different from "tear down the TLS session when we see a known
> extension which we don't plan to use".
>

In general, TLS has interpreted this kind of advice to include values which
are known to the implementation but configured off, but if you have clearer
text, I'm certainly open to it.

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7250)

[Eric Rescorla]

I don't believe this is correct.




On Mon, Nov 14, 2022 at 8:50 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7250
>
> --
> Type: Technical
> Reported by: Alan DeKok 
>
> Section: 4.6.1
>
> Original Text
> -
>The client MAY use this PSK for future handshakes by including the
>ticket value in the "pre_shared_key" extension in its ClientHello
>(Section 4.2.11).
>
> Corrected Text
> --
> (to add)
>
>   Where the client does not support session tickets, this extension MUST
> be ignored.
>


This proposed change would be wrong because you can support PSKs without
session tickets.


>
> Notes
> -
> I've seen a TLS implementation which doesn't implement session tickets.
> That's fine, but the implementation doesn't *ignore* session tickets it
> receives.  Instead, it treats reception of the ticket as un recoverable
> error, and drops the TLS connection.
>

> It's also worth adding a note to section 4.2 at the bottom of page 38.  To
> note that in general, f an extension isn't supported AND doesn't materially
> affect the TLS exchange, THEN it should be ignored.
>

S 4.1.2 says:
   extensions:  Clients request extended functionality from servers by
  sending data in the extensions field.  The actual "Extension"
  format is defined in Section 4.2.  In TLS 1.3, the use of certain
  extensions is mandatory, as functionality has moved into
  extensions to preserve ClientHello compatibility with previous
  versions of TLS.  Servers MUST ignore unrecognized extensions.



> i.e. there's nothing in the spec which mentions Postel's law "be
> conservative in what you send, be liberal in what you accept".  So
> implementors reading this document are free to do all kinds of odd things.
>

Well, I don't think we should cite Postel's law for reasons stated in
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-09.html

I do think this document should make clear cases where you are supposed to
ignore specific unknown values. I think it does that for this, but if you
have other examples, please file an issue on RFC 8446-bis:
https://github.com/tlswg/tls13-spec/


> In addition, the text in Section 4.2 at the bottom of page 38 says:
>
> "
>   Designers
>   and implementors should be aware of the fact that until the
>   handshake has been authenticated, active attackers can modify
>   messages and insert, remove, or replace extensions.
> "
>
> The implicit conclusion here is that an implementation receiving
> extensions must sanity check them.  e.g. an attacker adding an undefined /
> unknown extension should not cause the entire session to be torn down.
>

Because the keys are derived from the handshake transcript, an attacker
adding any extension or indeed changing any other part of the handshake
should cause the handshake to fail.

-Ekr


> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version
> 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls