Issues
--
* tlswg/draft-ietf-tls-esni (+0/-5/💬7)
4 issues received 7 new comments:
- #297 Proposal: Add version indication to ClientEncryptedCH (2 by cjpatton)
https://github.com/tlswg/draft-ietf-tls-esni/issues/297
- #290 What to do on ECH decryption failure? (1 by chris-wood)
ht
> On 11 Sep 2020, at 12:40, Nick Lamb wrote:
>
> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy wrote:
>
>> The MUD URL is encrypted and shared only with the authorized
>> components in the network. An attacker cannot read the MUD URL and
>> identify the IoT device. Otherwise, it provide
John,
The use of plain PSK makes a lot of sense because it provides the lowest
footprint solution for really constrained systems. Given that the LAKE group
wanted to focus on constrained IoT devices makes the decision by the group
questionable.
As you know, TLS 1.3 merged the handling of PSKs
The adoption call is now complete. Thanks to everyone who chimed in!
It seems we have consensus to adopt this draft as a WG item. Ekr, can you
please submit draft-ietf-tls-rfc8446-bis-00 when convenient?
Thanks,
Chris, on behalf of the chairs
On Wed, Sep 2, 2020, at 9:17 AM, Christopher Wood wr
I'm also fine with marking psk_ke as not recommended to be consistent with the
non-PFS ciphers, but there are plenty of valid use cases that justify keeping
dhe_psk_ke as recommended for external PSKs. Several of these use cases are
detailed in draft-ietf-tls-external-psk-guidance-00.
> On Se
