Hi Ben
Thanks for the response. Please see below.
>
> Agreed ... but this proposal appears to be predicated on a contrary
> assumption. It assumes that it is difficult for malware to learn the TLS
> profile of the device, and then proceeds to place this profile information in
> the (public)
Thanks Ben and Eliot for the feedback. Please see inline
On Tue, 15 Sep 2020 at 14:51, Eliot Lear wrote:
> Hi Ben
>
> Thanks for the response. Please see below.
>
> >
> > Agreed ... but this proposal appears to be predicated on a contrary
> assumption. It assumes that it is difficult for malwa
> My concern is not with "new extensions" per se. The hidden assumption here
> is that "extensions" are the only way TLS can evolve. In fact, future TLS
> versions are not constrained to evolve in any particular way. For example,
> future versions can introduce entirely new messages in the
Hi Achim,
On Fri, Sep 04, 2020 at 08:58:51AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> see my comments inline.
>
> Generally you may read the closed issues or PRs with the proper keywords
> in https://github.com/tlswg/dtls-conn-id.
>
> FMPOV most stuff has been discussed over and over. For me, in
On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
wrote:
>
>
>
> My concern is not with "new extensions" per se. The hidden assumption here
> is that "extensions" are the only way TLS can evolve. In fact, future TLS
> versions are not constrained to evolve in any particular way. For example,
> future
I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
The grease_extension parameter shouldn't exist, and there should be no
special handling for GREASE values. GREASE doesn't need to be mentioned in
this draft, except to say that a client may send values (cipher suites,
extens
Dan Brown 于2020年9月10日周四 下午11:18写道：
> *From:* TLS *On Behalf Of *Salz, Rich
> > Do we need a short RFC saying “do not use static DH” ?
>
>
>
> Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If
> so, then an RFC to ban static (EC)DH in TLS would need to be very clear
> abou
Hi Ben,
For receiving, if the tls12_cid content type is set, then the CID is
used to look up the connection and the security association. If the
tls12_cid content type is not set, then the connection and security
association is looked up by the 5-tuple and a check MUST be m
On Tue, 15 Sep 2020 at 18:39, Eliot Lear wrote:
>
>
> My concern is not with "new extensions" per se. The hidden assumption
> here is that "extensions" are the only way TLS can evolve. In fact, future
> TLS versions are not constrained to evolve in any particular way. For
> example, future ver
