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

[Joseph Salowey]

There is consensus to adopt this draft as a working group item.  I'll work
with the authors to migrate to the official repository and submit an
updated draft.

On Tue, May 21, 2024 at 11:23 AM Eric Rescorla  wrote:

> 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]

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

[David Benjamin]

Servers using DNSSEC won't help unless the client only honors the hint over
DNSSEC, and we do not live in a universe where DNSSEC succeeded to the
point that that's remotely viable.

I think that too can be discussed in detail post adoption, but I think such
a change would negate the value of this whole draft.

On Tue, May 21, 2024, 09:56 A A  wrote:

> In my opinion, to prevent downgrade attack, server MUST or SHOULD using
> DNSSEC when announcing DNS record.
>
>
> 21.05.2024, 21:48, "David Benjamin" :
>
> 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 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

[A A]

In my opinion, to prevent downgrade attack, server MUST or SHOULD using DNSSEC when announcing DNS record.21.05.2024, 21:48, "David Benjamin" :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.DavidOn 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.-EkrOn 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.orgTo 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

[David Benjamin]

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

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

[Bas Westerbaan]

I support adoption, and am happy to review.

On Sat, May 4, 2024 at 12:05 AM 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]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[David Benjamin]

This document does not make any changes to the DNS queries made. It merely
adds a parameter to the existing HTTPS-RR/SVCB record, with pre-existing
rules on who queries it and when, and describes how TLS can use it.

The interaction between HTTPS-RR and proxies is complex and all already
covered by RFC 9460. It sounds like you may be assuming that the TLS client
would start querying this in an otherwise unmodified proxy connection flow,
but the reality is more complex than that, due to the need to support, e.g.
multi-CDN flows.

Rather, I would expect that many proxy deployments to lose the record and
fail to apply this optimization altogether (with all the costs that entails
during PQ KEM transitions) because no one has yet defined a way for client
and proxy to coordinate on the split responsibilities. (Unless someone has
started this already and I missed it?) If this is a space you're interested
in, I think there is work to be done here.

Regardless, it's orthogonal to this document, which merely allocates a
parameter type.

David

On Mon, May 6, 2024, 08:31 Roelof duToit  wrote:

> The concept does indeed solve an important problem, but also introduces a
> new dependency in an environment that uses explicit proxies (mostly
> enterprise networks). In that environment this proposal, alongside ECH,
> introduces DNS queries at the TLS client endpoint where previously the DNS
> control point was limited to the proxy.  It would be good to mention that
> in the document.
>
> —Roelof
>
>
> On May 3, 2024, at 6:09 PM, David Benjamin  wrote:
>
> Unsurprisingly, I support adoption. :-)
>
> On Fri, May 3, 2024 at 6: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
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org