Re: [TLS] PQC key exchange sizes

[Sofía Celi]

Dear, all,

I wrote some of the open challenges of putting post-quantum cryptography 
into protocols over here: https://sofiaceli.com/thoughts/Taxonomy.pdf 
The document is very open ended atm but the idea is to develop into a 
list of concrete problems.


As I mentioned on our talk at the TLS WG meeting, I am planning a next 
instation of this workshop for around November to precesily talk about 
these challenges (the website is not yet updated as some people have 
asked ;)): https://sofiaceli.com/PQNet-Workshop/ I'll send a reminder to 
this list once there is more information about it.


Thank you,

On 27/07/2022 21:54, Rob Sayre wrote:

Hi,

There's also data from the old Chrome/Cloudflare experiment, in the 
discussion section:
https://blog.cloudflare.com/the-tls-post-quantum-experiment/ 



I /think/ the discussion says that sending handshake messages somewhat 
above the MTU didn't matter much, except on the slowest connections. 
They do hesitate to settle on a reason for that.


As for compatibility in general, it seems premature to worry about. If 
an implementation adds PQC support, and finds it doesn't work for 
underlying fragmentation reasons, they'll surely have to fix that too.


thanks,
Rob


On Wed, Jul 27, 2022 at 12:06 PM Bas Westerbaan 
> wrote:


On the QUIC side, there is the "*Q*uantum Ready" interop test:


https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370





On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos
mailto:40amazon@dmarc.ietf.org>> wrote:

Gotcha. This is a reasonable explanation for a potential
problem, but I would also like to see experimental proof that
DTLS implementation X, Y, Z have the problem. TLS
implementations don't deal with big ClientHellos today so we
could assume they would have a problem, but when tested they do
OK for the most part.


-Original Message-
From: TLS mailto:tls-boun...@ietf.org>>
On Behalf Of Ilari Liusvaara
Sent: Wednesday, July 27, 2022 10:42 AM
To: mailto:tls@ietf.org>> mailto:tls@ietf.org>>
Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes

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



On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
 > Hi Ilari,
 >
 > > - DTLS-level fragmentation. There are buggy implementations
that
 > >   break if one tries this.
 >
 > DTLS servers have been fragmenting and sending cert chains
that don’t
 > fit in the MTU for a long time. Is this buggy on the TLS
client side?

These problems are specific to fragmenting Client Hello.
Handling fragmented DTLS Client Hello is different from handling
fragmented DTLS Certificate (and even more so in DTLS 1.3). I
think DTLS specification just pretends both cases are the same.
They are not.


QUIC implementations could have similar issues with multiple
initial packets, but operating QUIC with fast
failure-independent fallback would make failures soft.


There is the general principle that if some protocol feature is
not used in the wild, it tends to break, even if required part
of the protocol. Either by implementation being poorly tested
and buggy, assuming the feature does not exist, or being missing
entierely.
Combine this with interop failures having outsize impact and old
versions sticking around far longer than desriable. And I do not
think fragmented Client Hellos in DTLS or multiple initials in
QUIC are seen much.


One trick with DTLS would be sending client hello with no key
shares. Causes extra round-trip, but any server that selects PQC
causing fragmentation would presumably be capable of handling that.



-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


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

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other
hacks.
It would have a higher implementation overhead, but also might be more
likely to be deployable.

I checked search.censys.io and there appear to be around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a
guarantee
that some of them will break with sending something new in an existing SNI
extension...

Erik


On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
wrote:

> I agree this is quite a compatibility risk. In addition to messing with
> SNI lookup, there are servers that try to correlate TLS SNI and HTTP Host.
> Indeed, when we accidentally sent IP literals in SNI, we broke a server
> that tried to do that but got very confused by the colons in an IPv6
> literal. That server would likely also be confused by this draft, less by
> syntax and more by SNI/Host mismatch. I would be surprised if this option
> were viable.
>
> Another option, which doesn't require redefining existing fields, is to
> simply allocate a new extension. Though I agree with Martin that one would
> expect the server to know its own IP. If you implicitly interpret a missing
> server_name extension as "I want the IP cert for this connection's IP",
> it's already unambiguous. Granted, there may be edge cases because missing
> server_name can also mean "I want the default cert" and perhaps your
> "default" cert and IP cert are different.
>
> On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson  wrote:
>
>> Hi Erik,
>>
>> As far as it goes, this might work.  However, I'm not sure about the
>> effect of this on compatibility.  I'm concerned that maybe this would end
>> up causing some servers to choke.  Servers that receive SNI can sometimes
>> use that SNI value to lookup the correct certificate.  Your design could
>> have those servers searching for a certificate that doesn't exist.
>>
>> Anything along these lines would need to be tested for compatibility -
>> extensively - before it could even be trialed.
>>
>> (I never saw the DDR as having deployment problems along these lines.  It
>> isn't THAT hard to know your own IP address for that purpose.)
>>
>> On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
>> > Following discussions in ADD around the DDR draft (as well as in UTA
>> > around Martin Thomson's PR to add IP address SANs to 6125-bis),
>> > I wrote up a draft on how IP addresses might be represented in SNI:
>> >
>> >   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>> >
>> > There are at least three different ways we could do it, but this draft
>> > proposes what seems to be the least bad while also talking about the
>> > other alternatives.  (I suspect we'd want to move the alternatives
>> > to an appendix or remove entirely from a final version.)
>> >
>> > Is this interesting to the working group?
>> > While IP address SANs have a bunch of corner cases and gaps,
>> > they do seem to be picking up new uses.
>> >
>> > What motivated me to realize we need to solve this is that
>> > draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
>> > client connecting to an IP address and expecting to see a SAN
>> > (where returning a cert associated with the IP address containing
>> > a SAN that the client connected to is straight-forward),
>> > DDR has clients connecting to a different IP and then
>> > expects to find an original IP also in the SAN list.
>> > This means that for an ISP with a large number of IPs
>> > (or using a services who operates DoH service on-behalf
>> > of many entities), you'd need to quickly/wastefully burn through IPv4
>> > addresses to enable a unique cert per original IP.
>> >
>> > Erik
>> >
>> >
>> > -- Forwarded message -
>> > From: 
>> > Date: Wed, Jul 27, 2022 at 2:20 PM
>> > Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
>> > To: Erik Nygren mailto:erik%2bi...@nygren.org>>,
>>
>> > Rich Salz 
>> >
>> >
>> >
>> > A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
>> > has been successfully submitted by Erik Nygren and posted to the
>> > IETF repository.
>> >
>> > Name:   draft-nygren-tls-ip-in-sni
>> > Revision:   00
>> > Title:  Representing IP addresses in TLS Server Name Indication
>> > (SNI)
>> > Document date:  2022-07-27
>> > Group:  Individual Submission
>> > Pages:  7
>> > URL:
>> > https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
>> > Status:
>> > https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>> > Htmlized:
>> > https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni
>> >
>> >
>> > Abstract:
>> >This specification provides a mechanism for clients to send IP
>> >addresses in a TLS Server Name Indication (SNI) extension as part of
>> >TLS handshakes, allowing servers to return a 

Re: [TLS] PQC key exchange sizes

[Rob Sayre]

Hi,

There's also data from the old Chrome/Cloudflare experiment, in the
discussion section:
https://blog.cloudflare.com/the-tls-post-quantum-experiment/

I /think/ the discussion says that sending handshake messages somewhat
above the MTU didn't matter much, except on the slowest connections. They
do hesitate to settle on a reason for that.

As for compatibility in general, it seems premature to worry about. If an
implementation adds PQC support, and finds it doesn't work for underlying
fragmentation reasons, they'll surely have to fix that too.

thanks,
Rob


On Wed, Jul 27, 2022 at 12:06 PM Bas Westerbaan  wrote:

> On the QUIC side, there is the "*Q*uantum Ready" interop test:
>
>
> https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370
>
>
>
> On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos  40amazon@dmarc.ietf.org> wrote:
>
>> Gotcha. This is a reasonable explanation for a potential problem, but I
>> would also like to see experimental proof that DTLS implementation X, Y, Z
>> have the problem. TLS implementations don't deal with big ClientHellos
>> today so we could assume they would have a problem, but when tested they do
>> OK for the most part.
>>
>>
>> -Original Message-
>> From: TLS  On Behalf Of Ilari Liusvaara
>> Sent: Wednesday, July 27, 2022 10:42 AM
>> To:  
>> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe.
>>
>>
>>
>> On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
>> > Hi Ilari,
>> >
>> > > - DTLS-level fragmentation. There are buggy implementations that
>> > >   break if one tries this.
>> >
>> > DTLS servers have been fragmenting and sending cert chains that don’t
>> > fit in the MTU for a long time. Is this buggy on the TLS client side?
>>
>> These problems are specific to fragmenting Client Hello. Handling
>> fragmented DTLS Client Hello is different from handling fragmented DTLS
>> Certificate (and even more so in DTLS 1.3). I think DTLS specification just
>> pretends both cases are the same. They are not.
>>
>>
>> QUIC implementations could have similar issues with multiple initial
>> packets, but operating QUIC with fast failure-independent fallback would
>> make failures soft.
>>
>>
>> There is the general principle that if some protocol feature is not used
>> in the wild, it tends to break, even if required part of the protocol.
>> Either by implementation being poorly tested and buggy, assuming the
>> feature does not exist, or being missing entierely.
>> Combine this with interop failures having outsize impact and old versions
>> sticking around far longer than desriable. And I do not think fragmented
>> Client Hellos in DTLS or multiple initials in QUIC are seen much.
>>
>>
>> One trick with DTLS would be sending client hello with no key shares.
>> Causes extra round-trip, but any server that selects PQC causing
>> fragmentation would presumably be capable of handling that.
>>
>>
>>
>> -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
>>
> ___
> 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] Representing IP addresses in SNI -- proposed draft

[David Benjamin]

I agree this is quite a compatibility risk. In addition to messing with SNI
lookup, there are servers that try to correlate TLS SNI and HTTP Host.
Indeed, when we accidentally sent IP literals in SNI, we broke a server
that tried to do that but got very confused by the colons in an IPv6
literal. That server would likely also be confused by this draft, less by
syntax and more by SNI/Host mismatch. I would be surprised if this option
were viable.

Another option, which doesn't require redefining existing fields, is to
simply allocate a new extension. Though I agree with Martin that one would
expect the server to know its own IP. If you implicitly interpret a missing
server_name extension as "I want the IP cert for this connection's IP",
it's already unambiguous. Granted, there may be edge cases because missing
server_name can also mean "I want the default cert" and perhaps your
"default" cert and IP cert are different.

On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson  wrote:

> Hi Erik,
>
> As far as it goes, this might work.  However, I'm not sure about the
> effect of this on compatibility.  I'm concerned that maybe this would end
> up causing some servers to choke.  Servers that receive SNI can sometimes
> use that SNI value to lookup the correct certificate.  Your design could
> have those servers searching for a certificate that doesn't exist.
>
> Anything along these lines would need to be tested for compatibility -
> extensively - before it could even be trialed.
>
> (I never saw the DDR as having deployment problems along these lines.  It
> isn't THAT hard to know your own IP address for that purpose.)
>
> On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
> > Following discussions in ADD around the DDR draft (as well as in UTA
> > around Martin Thomson's PR to add IP address SANs to 6125-bis),
> > I wrote up a draft on how IP addresses might be represented in SNI:
> >
> >   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
> >
> > There are at least three different ways we could do it, but this draft
> > proposes what seems to be the least bad while also talking about the
> > other alternatives.  (I suspect we'd want to move the alternatives
> > to an appendix or remove entirely from a final version.)
> >
> > Is this interesting to the working group?
> > While IP address SANs have a bunch of corner cases and gaps,
> > they do seem to be picking up new uses.
> >
> > What motivated me to realize we need to solve this is that
> > draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
> > client connecting to an IP address and expecting to see a SAN
> > (where returning a cert associated with the IP address containing
> > a SAN that the client connected to is straight-forward),
> > DDR has clients connecting to a different IP and then
> > expects to find an original IP also in the SAN list.
> > This means that for an ISP with a large number of IPs
> > (or using a services who operates DoH service on-behalf
> > of many entities), you'd need to quickly/wastefully burn through IPv4
> > addresses to enable a unique cert per original IP.
> >
> > Erik
> >
> >
> > -- Forwarded message -
> > From: 
> > Date: Wed, Jul 27, 2022 at 2:20 PM
> > Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
> > To: Erik Nygren mailto:erik%2bi...@nygren.org>>,
> > Rich Salz 
> >
> >
> >
> > A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
> > has been successfully submitted by Erik Nygren and posted to the
> > IETF repository.
> >
> > Name:   draft-nygren-tls-ip-in-sni
> > Revision:   00
> > Title:  Representing IP addresses in TLS Server Name Indication
> > (SNI)
> > Document date:  2022-07-27
> > Group:  Individual Submission
> > Pages:  7
> > URL:
> > https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni
> >
> >
> > Abstract:
> >This specification provides a mechanism for clients to send IP
> >addresses in a TLS Server Name Indication (SNI) extension as part of
> >TLS handshakes, allowing servers to return a certificate containing
> >that subjectAltName.  This is done by converting the IP address to a
> >special-use domain name.
> >
> >
> >
> >
> > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Martin Thomson]

Hi Erik,

As far as it goes, this might work.  However, I'm not sure about the effect of 
this on compatibility.  I'm concerned that maybe this would end up causing some 
servers to choke.  Servers that receive SNI can sometimes use that SNI value to 
lookup the correct certificate.  Your design could have those servers searching 
for a certificate that doesn't exist.

Anything along these lines would need to be tested for compatibility - 
extensively - before it could even be trialed.

(I never saw the DDR as having deployment problems along these lines.  It isn't 
THAT hard to know your own IP address for that purpose.)

On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
> Following discussions in ADD around the DDR draft (as well as in UTA
> around Martin Thomson's PR to add IP address SANs to 6125-bis),
> I wrote up a draft on how IP addresses might be represented in SNI:
>
>   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>
> There are at least three different ways we could do it, but this draft
> proposes what seems to be the least bad while also talking about the 
> other alternatives.  (I suspect we'd want to move the alternatives 
> to an appendix or remove entirely from a final version.)
>
> Is this interesting to the working group?
> While IP address SANs have a bunch of corner cases and gaps,
> they do seem to be picking up new uses.  
>
> What motivated me to realize we need to solve this is that 
> draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the 
> client connecting to an IP address and expecting to see a SAN
> (where returning a cert associated with the IP address containing
> a SAN that the client connected to is straight-forward),
> DDR has clients connecting to a different IP and then
> expects to find an original IP also in the SAN list.  
> This means that for an ISP with a large number of IPs
> (or using a services who operates DoH service on-behalf
> of many entities), you'd need to quickly/wastefully burn through IPv4 
> addresses to enable a unique cert per original IP.
>
> Erik
>
>
> -- Forwarded message -
> From: 
> Date: Wed, Jul 27, 2022 at 2:20 PM
> Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
> To: Erik Nygren mailto:erik%2bi...@nygren.org>>, 
> Rich Salz 
>
>
>
> A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
> has been successfully submitted by Erik Nygren and posted to the
> IETF repository.
>
> Name:   draft-nygren-tls-ip-in-sni
> Revision:   00
> Title:  Representing IP addresses in TLS Server Name Indication 
> (SNI)
> Document date:  2022-07-27
> Group:  Individual Submission
> Pages:  7
> URL:
> https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni
>
>
> Abstract:
>This specification provides a mechanism for clients to send IP
>addresses in a TLS Server Name Indication (SNI) extension as part of
>TLS handshakes, allowing servers to return a certificate containing
>that subjectAltName.  This is done by converting the IP address to a
>special-use domain name.
>
>
>
>
> 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] PQC key exchange sizes

[Bas Westerbaan]

On the QUIC side, there is the "*Q*uantum Ready" interop test:


https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370



On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos  wrote:

> Gotcha. This is a reasonable explanation for a potential problem, but I
> would also like to see experimental proof that DTLS implementation X, Y, Z
> have the problem. TLS implementations don't deal with big ClientHellos
> today so we could assume they would have a problem, but when tested they do
> OK for the most part.
>
>
> -Original Message-
> From: TLS  On Behalf Of Ilari Liusvaara
> Sent: Wednesday, July 27, 2022 10:42 AM
> To:  
> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
> > Hi Ilari,
> >
> > > - DTLS-level fragmentation. There are buggy implementations that
> > >   break if one tries this.
> >
> > DTLS servers have been fragmenting and sending cert chains that don’t
> > fit in the MTU for a long time. Is this buggy on the TLS client side?
>
> These problems are specific to fragmenting Client Hello. Handling
> fragmented DTLS Client Hello is different from handling fragmented DTLS
> Certificate (and even more so in DTLS 1.3). I think DTLS specification just
> pretends both cases are the same. They are not.
>
>
> QUIC implementations could have similar issues with multiple initial
> packets, but operating QUIC with fast failure-independent fallback would
> make failures soft.
>
>
> There is the general principle that if some protocol feature is not used
> in the wild, it tends to break, even if required part of the protocol.
> Either by implementation being poorly tested and buggy, assuming the
> feature does not exist, or being missing entierely.
> Combine this with interop failures having outsize impact and old versions
> sticking around far longer than desriable. And I do not think fragmented
> Client Hellos in DTLS or multiple initials in QUIC are seen much.
>
>
> One trick with DTLS would be sending client hello with no key shares.
> Causes extra round-trip, but any server that selects PQC causing
> fragmentation would presumably be capable of handling that.
>
>
>
> -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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PQC key exchange sizes

[Kampanakis, Panos]

Gotcha. This is a reasonable explanation for a potential problem, but I would 
also like to see experimental proof that DTLS implementation X, Y, Z have the 
problem. TLS implementations don't deal with big ClientHellos today so we could 
assume they would have a problem, but when tested they do OK for the most part.
 

-Original Message-
From: TLS  On Behalf Of Ilari Liusvaara
Sent: Wednesday, July 27, 2022 10:42 AM
To:  
Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes

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



On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
> Hi Ilari,
>
> > - DTLS-level fragmentation. There are buggy implementations that
> >   break if one tries this.
>
> DTLS servers have been fragmenting and sending cert chains that don’t 
> fit in the MTU for a long time. Is this buggy on the TLS client side?

These problems are specific to fragmenting Client Hello. Handling fragmented 
DTLS Client Hello is different from handling fragmented DTLS Certificate (and 
even more so in DTLS 1.3). I think DTLS specification just pretends both cases 
are the same. They are not.


QUIC implementations could have similar issues with multiple initial packets, 
but operating QUIC with fast failure-independent fallback would make failures 
soft.


There is the general principle that if some protocol feature is not used in the 
wild, it tends to break, even if required part of the protocol. Either by 
implementation being poorly tested and buggy, assuming the feature does not 
exist, or being missing entierely.
Combine this with interop failures having outsize impact and old versions 
sticking around far longer than desriable. And I do not think fragmented Client 
Hellos in DTLS or multiple initials in QUIC are seen much.


One trick with DTLS would be sending client hello with no key shares. Causes 
extra round-trip, but any server that selects PQC causing fragmentation would 
presumably be capable of handling that.



-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

[TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

Following discussions in ADD around the DDR draft (as well as in UTA
around Martin Thomson's PR to add IP address SANs to 6125-bis),
I wrote up a draft on how IP addresses might be represented in SNI:

  https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/

There are at least three different ways we could do it, but this draft
proposes what seems to be the least bad while also talking about the
other alternatives.  (I suspect we'd want to move the alternatives
to an appendix or remove entirely from a final version.)

Is this interesting to the working group?
While IP address SANs have a bunch of corner cases and gaps,
they do seem to be picking up new uses.

What motivated me to realize we need to solve this is that
draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
client connecting to an IP address and expecting to see a SAN
(where returning a cert associated with the IP address containing
a SAN that the client connected to is straight-forward),
DDR has clients connecting to a different IP and then
expects to find an original IP also in the SAN list.
This means that for an ISP with a large number of IPs
(or using a services who operates DoH service on-behalf
of many entities), you'd need to quickly/wastefully burn through IPv4
addresses to enable a unique cert per original IP.

Erik


-- Forwarded message -
From: 
Date: Wed, Jul 27, 2022 at 2:20 PM
Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
To: Erik Nygren , Rich Salz 



A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.

Name:   draft-nygren-tls-ip-in-sni
Revision:   00
Title:  Representing IP addresses in TLS Server Name Indication
(SNI)
Document date:  2022-07-27
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
Status: https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni


Abstract:
   This specification provides a mechanism for clients to send IP
   addresses in a TLS Server Name Indication (SNI) extension as part of
   TLS handshakes, allowing servers to return a certificate containing
   that subjectAltName.  This is done by converting the IP address to a
   special-use domain name.




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

Re: [TLS] PQC key exchange sizes

[Ilari Liusvaara]

On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
> Hi Ilari,
> 
> > - DTLS-level fragmentation. There are buggy implementations that
> >   break if one tries this.
> 
> DTLS servers have been fragmenting and sending cert chains that don’t
> fit in the MTU for a long time. Is this buggy on the TLS client side?

These problems are specific to fragmenting Client Hello. Handling
fragmented DTLS Client Hello is different from handling fragmented
DTLS Certificate (and even more so in DTLS 1.3). I think DTLS
specification just pretends both cases are the same. They are not.


QUIC implementations could have similar issues with multiple initial
packets, but operating QUIC with fast failure-independent fallback
would make failures soft.


There is the general principle that if some protocol feature is not
used in the wild, it tends to break, even if required part of the
protocol. Either by implementation being poorly tested and buggy,
assuming the feature does not exist, or being missing entierely.
Combine this with interop failures having outsize impact and old
versions sticking around far longer than desriable. And I do not think
fragmented Client Hellos in DTLS or multiple initials in QUIC are seen
much.


One trick with DTLS would be sending client hello with no key
shares. Causes extra round-trip, but any server that selects PQC
causing fragmentation would presumably be capable of handling that.



-Ilari

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

Re: [TLS] PQC key exchange sizes

[Martin Thomson]

On Tue, Jul 26, 2022, at 22:21, Kampanakis, Panos wrote:
> Why are 2-3 packet CHs unworkable?

Loss probability is a contributing factor for sure, but the thing that really 
hurts is the extra round trip that many servers will induce when they cannot 
process the TLS ClientHello in one go.

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