[TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites
Hi, In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get removed, and key_share extension applies to non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4279. Per the draft spec of TLS 1.3, if no suitable identity is provided in pre-shared key extension, the server MUST NOT negotiate a PSK cipher suite. The question comes to me: where the suitable identity comes from? The identity can be acquired by out-of-band approach, or the server NewSessionTicket message. If no out-of-band approach in some circumstances, the server NewSessionTicket message would be the only way to create the identity. The scenarios of using pre-shared key may look like: 1. establish a fresh connection, server sends the NewSessionTicket to indicate it supports session resumption and provide the psk_identity. 2. if client wants a session resumption, subsequent handshaking will use pre_shared key extension with the server provided psk_identity. Looks like PSK applies to session resume only in TLS 1.3, and cannot be used for fresh (initial) handshaking any more, unless out-of-band approach is used to define the identities. I have no experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used previously. It would be nice to consider and specify the impact on RFC 4279 in TLS 1.3 protocols. Regards, Xuelei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
On Friday 27 November 2015 10:50:40 Xuelei Fan wrote: > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > > Can key_share offers two shares for the same group? > > > > It's currently worded "Clients MUST NOT offer multiple KeyShareEntry > > values for the same parameters", which is a little ambiguous, but I > > interpret this as one share per group. I don't know why you'd need > > to offer more than one, anyway. > > > Need no more than one. Then, it may be more simple that key_share > does > not define the preference order. The preference order is covered by > supported_groups. What would then be the expected behaviour of the server if the first group in the supported_groups does not have a associated key share? that is, I advertise support for secp384r1, secp256r1 or ffdhe2048, but I provide only secp256r1 key share as it's the one that's most widely supported Should the server ask me to provide a secp384r1 key share or should it just proceed with secp256r1? I think that specifying *both* in preference order, and recommending the servers to first inspect key shares and then supported_groups (if no intersect between what server supports and what key shares client provided) would end up with more predictable behaviour and cleaner code. That being said, we probably should say that clients MUST advertise support for all groups for which they send key shares and servers MUST abort connection with something like illegal_parameter if that happens -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario wrote: > On Friday 27 November 2015 10:50:40 Xuelei Fan wrote: > > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > > > Can key_share offers two shares for the same group? > > > > > > It's currently worded "Clients MUST NOT offer multiple KeyShareEntry > > > values for the same parameters", which is a little ambiguous, but I > > > interpret this as one share per group. I don't know why you'd need > > > to offer more than one, anyway. > > > > > Need no more than one. Then, it may be more simple that key_share > > does > > not define the preference order. The preference order is covered by > > supported_groups. > > What would then be the expected behaviour of the server if the first > group in the supported_groups does not have a associated key share? > > Try the next group in the supported_groups until find an associated key share. > that is, I advertise support for secp384r1, secp256r1 or ffdhe2048, but > I provide only secp256r1 key share as it's the one that's most widely > supported > > Should the server ask me to provide a secp384r1 key share or should it > just proceed with secp256r1? > > I think, it would be better to proceed with secp256r1. > I think that specifying *both* in preference order, and recommending the > servers to first inspect key shares and then supported_groups (if no > intersect between what server supports and what key shares client > provided) would end up with more predictable behaviour and cleaner code. > > But if the orders are not consistent, the logic get annoyed. It's a good practice to keep the order consistent, but it would be better if the preference order is unique and specified in one place. > > That being said, we probably should say that clients MUST advertise > support for all groups for which they send key shares and servers MUST > abort connection with something like illegal_parameter if that happens > This adds additional checking on both client and server. Personally, I would prefer to use one preference order in order to avoid any order conflict. Thanks & Regards, Xuelei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
On Friday 27 November 2015 20:33:46 Xuelei Fan wrote: > On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario wrote: > > On Friday 27 November 2015 10:50:40 Xuelei Fan wrote: > > > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > > > > Can key_share offers two shares for the same group? > > > > > > > > It's currently worded "Clients MUST NOT offer multiple > > > > KeyShareEntry > > > > values for the same parameters", which is a little ambiguous, > > > > but I > > > > interpret this as one share per group. I don't know why you'd > > > > need > > > > to offer more than one, anyway. > > > > > > Need no more than one. Then, it may be more simple that key_share > > > does > > > not define the preference order. The preference order is covered > > > by > > > supported_groups. > > > > What would then be the expected behaviour of the server if the first > > group in the supported_groups does not have a associated key share? > > > Try the next group in the supported_groups until find an associated > key > share. > > > I think that specifying *both* in preference order, and recommending > > the servers to first inspect key shares and then supported_groups > > (if no intersect between what server supports and what key shares > > client provided) would end up with more predictable behaviour and > > cleaner code. > > > But if the orders are not consistent, the logic get annoyed. It's a > good > practice to keep the order consistent, but it would be better if the > preference order is unique and specified in one place. that means that the code needs to keep references to two arrays at the same time and either create a hash table for lookups in key shares or iterate over key shares for every try - this makes code and logic more complex, not less > > That being said, we probably should say that clients MUST advertise > > support for all groups for which they send key shares and servers > > MUST abort connection with something like illegal_parameter if that > > happens > This adds additional checking on both client and server. Personally, > I would prefer to use one preference order in order to avoid any > order conflict. not the first, and certainly not the last checks that need to be done to implement TLS securely... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
> > > > I think that specifying *both* in preference order, and recommending > > > the servers to first inspect key shares and then supported_groups > > > (if no intersect between what server supports and what key shares > > > client provided) would end up with more predictable behaviour and > > > cleaner code. > > > > > But if the orders are not consistent, the logic get annoyed. It's a > > good > > practice to keep the order consistent, but it would be better if the > > preference order is unique and specified in one place. > > that means that the code needs to keep references to two arrays at the > same time and either create a hash table for lookups in key shares or > iterate over key shares for every try - this makes code and logic more > complex, not less > I did not get the idea, can the complex above be avoided if keeping both? Does one preference order just get ignored? If the orders are not consistent, if I can choose from two options: continue or alter, I would choose the continue option. Alert message is expensive in practice. Anyway, minor question, not a big concern to me. Thanks & Regards, Xuelei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
On Friday 27 November 2015 21:20:24 Xuelei Fan wrote: > > > > I think that specifying *both* in preference order, and > > > > recommending > > > > the servers to first inspect key shares and then > > > > supported_groups > > > > (if no intersect between what server supports and what key > > > > shares > > > > client provided) would end up with more predictable behaviour > > > > and > > > > cleaner code. > > > > > > But if the orders are not consistent, the logic get annoyed. It's > > > a > > > good > > > practice to keep the order consistent, but it would be better if > > > the > > > preference order is unique and specified in one place. > > > > that means that the code needs to keep references to two arrays at > > the same time and either create a hash table for lookups in key > > shares or iterate over key shares for every try - this makes code > > and logic more complex, not less > > I did not get the idea, can the complex above be avoided if keeping > both? Does one preference order just get ignored? the idea is that if there is a key share acceptable for the server, the supported_groups can be ignored but to make sure that clients don't start putting complete garbage there, we need to tell servers to check key shares against supported_groups > If the orders are not consistent, if I can choose from two options: > continue or alter, I would choose the continue option. alter what? > Alert message > is expensive in practice. Note that this alert will never be sent to a client that is behaving according to specification unless the packets were modified by the network. It's a sanity check. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
On Fri, Nov 27, 2015 at 9:28 PM, Hubert Kario wrote: > On Friday 27 November 2015 21:20:24 Xuelei Fan wrote: > > > > > I think that specifying *both* in preference order, and > > > > > recommending > > > > > the servers to first inspect key shares and then > > > > > supported_groups > > > > > (if no intersect between what server supports and what key > > > > > shares > > > > > client provided) would end up with more predictable behaviour > > > > > and > > > > > cleaner code. > > > > > > > > But if the orders are not consistent, the logic get annoyed. It's > > > > a > > > > good > > > > practice to keep the order consistent, but it would be better if > > > > the > > > > preference order is unique and specified in one place. > > > > > > that means that the code needs to keep references to two arrays at > > > the same time and either create a hash table for lookups in key > > > shares or iterate over key shares for every try - this makes code > > > and logic more complex, not less > > > > I did not get the idea, can the complex above be avoided if keeping > > both? Does one preference order just get ignored? > > the idea is that if there is a key share acceptable for the server, the > supported_groups can be ignored > > but to make sure that clients don't start putting complete garbage > there, we need to tell servers to check key shares against > supported_groups > > As the check needs additional effort, and the client code also needs additional effort to keep the order consistent, I think the logic may be more complex. Anyway, not a big concern to me. Personally, I prefer one logic one place. > > If the orders are not consistent, if I can choose from two options: > > continue or alter, I would choose the continue option. > > alter what? > > If the preference orders in key_share and supported_groups are not consistent, I think an alert message is expected. > > Alert message > > is expensive in practice. > > Note that this alert will never be sent to a client that is behaving > according to specification unless the packets were modified by the > network. It's a sanity check. > > Sure, if both peer strict follow the spec. But implementation may be not correct. Conner case, of course. Thanks & Regards, Xuelei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites
Hi Xuelei, As per RFC 4279 also, both the client and server are supposed to have a set of “Identity – key” pair on either sides. The “ServerKeyExchange.psk_identity_hint” only helps the client in choosing an “identity-key” pair from a list of several “identity-key pairs” the client may have. In TLS 1.3, instead of the ServerKeyExchange.psk_identity_hint, client sends its list of identities in the client hello itself through PreSharedKey Extension and server chooses one from it and replies in the PreSharedKey Extension. Now, instead of traditional session resumption, this logic will be used which basically has the same abbreviated handshake. So, essentially, TLS 1.2 to TLS 1.3 transition for the above scenario should be viewed as below: (a)In case of PSK, instead of Client guessing and using an Identity based on PSK Identity Hint, both client and server negotiate which identity to use in the hello messages itself. (b) ServerKeyExchange.psk_identity_hint can be obsoleted removed when you transition from 1.2 to 1.3. In my opinion, this makes the PSK based handshake a lot more simpler and easier to use. Could you elaborate on your scenario based on which you say the transition from TLS 1.2 to TLS 1.3 for PSK will be difficult? Regards, Jay *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *** From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan Sent: 27 November 2015 17:29 To: tls@ietf.org Subject: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites Hi, In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get removed, and key_share extension applies to non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4279. Per the draft spec of TLS 1.3, if no suitable identity is provided in pre-shared key extension, the server MUST NOT negotiate a PSK cipher suite. The question comes to me: where the suitable identity comes from? The identity can be acquired by out-of-band approach, or the server NewSessionTicket message. If no out-of-band approach in some circumstances, the server NewSessionTicket message would be the only way to create the identity. The scenarios of using pre-shared key may look like: 1. establish a fresh connection, server sends the NewSessionTicket to indicate it supports session resumption and provide the psk_identity. 2. if client wants a session resumption, subsequent handshaking will use pre_shared key extension with the server provided psk_identity. Looks like PSK applies to session resume only in TLS 1.3, and cannot be used for fresh (initial) handshaking any more, unless out-of-band approach is used to define the identities. I have no experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used previously. It would be nice to consider and specify the impact on RFC 4279 in TLS 1.3 protocols. Regards, Xuelei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Encrypting record headers: practical for TLS 1.3 after all?
The idea of encrypting TLS record headers has come up before, the most
important purpose being to hide record lengths and boundaries and make
fingerprinting and traffic analysis harder. I had convinced myself that
goal this would be "too hard" to accomplish in TLS 1.3, but after
further thought I'm not so sure. So I would like to request comment on
one approach that strikes me as a practical and requires only a rather
minor change to the current spec.
The quick summary:
* To encrypt a record, we first AEAD-encrypt the record's payload,
protecting the header fields via the additional_data, exactly as
currently specified. But then we XOR-encrypt the 5-byte TLS header just
before transmission, using a (separate) stream cipher indexed by a nonce
that depends on record sequence number and *_write_iv, in exactly the
same way the AEAD is already nonce-indexed.
* To decrypt a record, we simply do the reverse: first use the stream
cipher with the appropriate nonce to XOR-decrypt the 5-byte TLS header,
then sanity-check it as usual to determine its length, read the rest of
the record, and submit it to AEAD for decryption and full integrity
checking as before.
That's it, in a nutshell. Two likely concerns immediately arise,
discussed below, but feel free to TL;DR the rest if you don't share
these concerns.
---
Concern #1: What if an active attacker messes with the TLS header,
especially the length field, since stream ciphers don't protect
integrity? The simple answer is that *exactly* the same thing happens
as now: the AEAD decryption attempt fails, because the
(stream-decrypted) header is AEAD-protected as additional_data. Nothing
is gained or lost.
SSH, which did something like this, ran into trouble with attackers
being able to twiddle the record length field to make the record length
look big, causing the receiver to try to receive a very large record,
and hence appear to the user to hang, instead of immediately detecting
the modification and terminating the connection. But there are three
mitigating factors here: (1) TLS is not usually used for interactive
terminal traffic like SSH is; (2) TLS's 2-byte record length field
imposes a pretty reasonable upper-bound on the maximum size an attacker
could maliciously make a record appear to be; and (3) if this risk of
length-twiddling is at all a problem in this proposed encrypted-header
protocol, then it's already a problem for the current TLS 1.3 spec
without encrypted headers, because active attackers can twiddle the bits
of a cleartext length field just as easily (and even be *certain* they
are making the length appear large!). So I can't see any way this
length-twiddling vulnerability becomes any worse, and maybe it gets a
bit better (because the attacker can no longer be entirely certain
whether he's setting a 1 bit to 0 or a 0 bit to 1).
---
Concern #2: Do we want to have to go to the trouble of adding a stream
cipher to every TLS 1.3-compatible ciphersuite? Answer: maybe not, but
we don't necessarily need to. We could instead just specify a generic
method of using the ciphersuite's main AEAD as a stream cipher for
header encryption/decryption purposes.
The conceptually simplest approach I can think of: In the specification
of how AEAD nonces are generated (section 5.2.2 of
draft-ietf-tls-tls13-07), reserve the least-significant bit of the
record sequence number, so that sequence numbers increment by 2 rather
than 1 each record. Thus, we get two unique nonces per record from the
same set of symmetric keys. We first use the nonce with a '0'
least-significant bit to perform the regular AEAD-encryption of the
record with the header info as additional_data.
Then for the same record we use the nonce with a '1' least-significant
to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use
the first five bytes of result as the cipherstream to XOR the 5-byte TLS
header with before transmitting. The AEAD will of course uselessly
append some kind of authenticator to this ciphertext that we won't end
up using, but that's OK. The receiver will just use AEAD-encrypt
(again) on the same five-zero-byte message to reproduce the 5
cipherstream bytes with which to decrypt the TLS header. Thus, senders
perform two AEAD-encrypts per record, and receivers do one AEAD-encrypt
and one AEAD-decrypt per record.
This approach seems pretty conceptually clean and simple, but has the
performance downside that we always need to invoke the AEAD twice per
record rather than once, which might be (a bit) costly especially when
records are small. So a simple refinement is to amortize this cost
across records: e.g., once every 256 records (every sequence number
ending in 0x00) we AEAD-encrypt a sequence of 5*256=1280 zero bytes, and
the result in 5-byte chunks as the cipherstream with which to encrypt
and decrypt 256 consecutive TLS record headers. Thus, we're only adding
one additional AEAD-encryption of a "normal-packet-sized" 1280-byte blob
once every 256 r
Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites
It is a great idea to use PSK for session resumption. However, as the ServerKeyExchange.psk_identity_hint disappears in TLS 1.3, I was wondering, it may be not easy to make an upgrade for those PSK implementation that relies on ServerKeyExchange.psk_identity_hint. Considering the following initial handshaking example in TLS 1.2. 1. client requests a PSK cipher suite negotiation; 2. server responses with a hint in ServerKeyExchange.psk_identity_hint 3. client looks for the shared key with the hint in the local database/cache/remote service, etc. 4. client provides the shared key in ClientKeyExchange.psk_identity. Here ServerKeyExchange.psk_identity_hint is used as an index to find the shared key in client side. If moving to TLS 1.3, as there is no hint any more, application may need to reconstruct the scenarios above in order to follow the spec of TLS 1.3 and find a new approach to get the shared key. If the client and server are supposed to have a short set of known “Identity – key” pair on either sides between them, the reconstruction can be minimal. If the shared keys are unknown previously before the hint get known, the reconstruction would get complicated. Just guessing theoretically, I have no practical evidence for the case. Hopefully, no one use the case in practice. Regards, Xuelei On Fri, Nov 27, 2015 at 10:00 PM, Jayaraghavendran k < jayaraghavendra...@huawei.com> wrote: > Hi Xuelei, > > > > As per RFC 4279 also, both the client and server are supposed to have a > set of “Identity – key” pair on either sides. The > “ServerKeyExchange.psk_identity_hint” only helps the client in choosing an > “identity-key” pair from a list of several “identity-key pairs” the client > may have. > > > > In TLS 1.3, instead of the ServerKeyExchange.psk_identity_hint, client > sends its list of identities in the client hello itself through > PreSharedKey Extension and server chooses one from it and replies in the > PreSharedKey Extension. Now, instead of traditional session resumption, > this logic will be used which basically has the same abbreviated handshake. > > > > So, essentially, TLS 1.2 to TLS 1.3 transition for the above scenario > should be viewed as below: > > (a)In case of PSK, instead of Client guessing and using an Identity > based on PSK Identity Hint, both client and server negotiate which identity > to use in the hello messages itself. > > (b) ServerKeyExchange.psk_identity_hint can be obsoleted removed when > you transition from 1.2 to 1.3. > > > > In my opinion, this makes the PSK based handshake a lot more simpler and > easier to use. > > > > Could you elaborate on your scenario based on which you say the transition > from TLS 1.2 to TLS 1.3 for PSK will be difficult? > > > > Regards, > > Jay > > > > > *** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > > *** > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Xuelei Fan > *Sent:* 27 November 2015 17:29 > *To:* tls@ietf.org > *Subject:* [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites > > > > Hi, > > > > In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get > removed, and key_share extension applies to non-PSK cipher suites only. As > RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS > 1.3 updates or obsoletes RFC 4279. > > > > Per the draft spec of TLS 1.3, if no suitable identity is provided in > pre-shared key extension, the server MUST NOT negotiate a PSK cipher > suite. The question comes to me: where the suitable identity comes from? > The identity can be acquired by out-of-band approach, or the server > NewSessionTicket message. If no out-of-band approach in some > circumstances, the server NewSessionTicket message would be the only way to > create the identity. The scenarios of using pre-shared key may look like: > > 1. establish a fresh connection, server sends the NewSessionTicket to > indicate it supports session resumption and provide the psk_identity. > > 2. if client wants a session resumption, subsequent handshaking will use > pre_shared key extension with the server provided psk_identity. > > > > Looks like PSK applies to session resume only in TLS 1.3, and cannot be > used for fresh (initial) handshaking any more, unless out-of-band approach > is used to define the identities. I have no experience on PSK, but looks > like that it is not A
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 2015-11-27 15:35, Bryan A Ford wrote: The idea of encrypting TLS record headers has come up before, the most important purpose being to hide record lengths and boundaries and make fingerprinting and traffic analysis harder. How, exactly, would this be significantly harder? The adversary will still be able to tell when, and how much, TCP/IP data is sent between the peers. If there happens to be a revealing TLS record boundary in the middle of a TCP/IP packet, it would seem to me there is an implementation problem rather than a problem with the abstract protocol. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3
On 26 November 2015 at 18:38, Xuelei Fan wrote: > What's the consideration to place selected_group out of the extensions filed > in HelloRetryRequest? An extension would work, except that I believe that extensions in HelloRetryRequest are going to carry somewhat different semantics to those in other Hello messages. If we go to dynamically generated groups, then we can easily define a new FFDHE code point to signal the use of a dynamic group. Though I think that I'd be sad about having to always spend an extra round trip if it came to that. Also, it's not much, but the explicit field keeps the message (a tiny bit) smaller and easier to process. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3
It makes sense to me. It's OK if TLS 1.3 only supports (EC)DHE cipher suites. If it is extended to support other cipher suites, for example PSK or KRB5 cipher suites (which do not require named groups), the HelloRetryRequest.selected_group may be redundant if this extra RTT is required. As the ServerKeyExchange/ClientKeyExchange will be replaced with key_share extension, I'm still not sure of the impact on those cipher suites, including PSK and KRB5, that replies on ServerKeyExchange/ClientKeyExchange messages. Hopefully, no other cipher suites needs an extra RTT similar to HelloRetryRequest. Thanks & Regards, Xuelei On Sat, Nov 28, 2015 at 10:25 AM, Martin Thomson wrote: > On 26 November 2015 at 18:38, Xuelei Fan wrote: > > What's the consideration to place selected_group out of the extensions > filed > > in HelloRetryRequest? > > An extension would work, except that I believe that extensions in > HelloRetryRequest are going to carry somewhat different semantics to > those in other Hello messages. > > If we go to dynamically generated groups, then we can easily define a > new FFDHE code point to signal the use of a dynamic group. Though I > think that I'd be sad about having to always spend an extra round trip > if it came to that. > > Also, it's not much, but the explicit field keeps the message (a tiny > bit) smaller and easier to process. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
