Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id

2018-11-20 Thread Nikos Mavrogiannopoulos
On Wed, 2018-11-07 at 14:39 +0700, Joseph Salowey wrote: > This is the working group last call for the "Connection Identifiers > for DTLS 1.2" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/. > Please review the document and send your comments to the list b

[TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

2018-11-20 Thread M K Saravanan
Hi, If a TLSv1.2 Certificate Request message contains 0x0804 (rsa_pss_rsae_sha256) as one of the supported signature algorithms, can a client sign the CertificateVerify message using that algorithm? (client cert is RSA). Is it allowed in TLSv1.2? with regards, Saravanan

Re: [TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

2018-11-20 Thread M K Saravanan
Hi, RFC8446: = 4.2.3. Signature Algorithms [...] - Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3) MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. In TLS

Re: [TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

2018-11-20 Thread David Benjamin
Yes, this is correct. On Tue, Nov 20, 2018 at 10:35 AM M K Saravanan wrote: > Hi, > > RFC8446: > = > 4.2.3. Signature Algorithms > > [...] > - Implementations that advertise support for RSASSA-PSS (which is > mandatory in TLS 1.3) MUST be p

Re: [TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

2018-11-20 Thread M K Saravanan
Thanks David. with regards, Saravanan. On Wed, 21 Nov 2018 at 02:07, David Benjamin wrote: > > Yes, this is correct. > > On Tue, Nov 20, 2018 at 10:35 AM M K Saravanan wrote: >> >> Hi, >> >> RFC8446: >> = >> 4.2.3. Signature Algorithms >> >> [...]

[TLS] ESNIKeys over complex

2018-11-20 Thread Stephen Farrell
Hiya, I've started to try code up an openssl version of this. [1] (Don't be scared though, it'll likely be taken over by a student in the new year:-) From doing that I think the ESNIKeys structure is too complicated and could do with a bunch of changes. The ones I'd argue for would be: - use a

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Eric Rescorla
On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell wrote: > > Hiya, > > I've started to try code up an openssl version of this. [1] > (Don't be scared though, it'll likely be taken over by a > student in the new year:-) > Thanks for your comments. Responses below. >From doing that I think the ESNI

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Stephen Farrell
Hiya, On 20/11/2018 23:30, Eric Rescorla wrote: > On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell > wrote: > >> >> Hiya, >> >> I've started to try code up an openssl version of this. [1] >> (Don't be scared though, it'll likely be taken over by a >> student in the new year:-) >> > > Thanks for

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Eric Rescorla
On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell wrote: > > Hiya, > > On 20/11/2018 23:30, Eric Rescorla wrote: > > On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> I've started to try code up an openssl version of this. [1] >

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Stephen Farrell
(Trimming bits down...) On 21/11/2018 00:59, Eric Rescorla wrote: > On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell >> Aren't DNS answers RRsets? I may be wrong but I thought DNS >> clients have to handle that anyway, > > > Not really, because any of them is co-valid. Sure, in DNS terms. >

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Salz, Rich
>Sure a list of ciphersuites isn't bad. But the current design has a set of keys and a set of ciphersuites and a set of extensions and a set of Rdata values in the RRset. Since this is defined for TLS 1.3 with all known-good ciphers, can't that field be eliminated? >I'd bet a b

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Eric Rescorla
On Tue, Nov 20, 2018 at 6:04 PM Salz, Rich wrote: > >Sure a list of ciphersuites isn't bad. But the current > design has a set of keys and a set of ciphersuites and a > set of extensions and a set of Rdata values in the RRset. > > Since this is defined for TLS 1.3 with all known-good

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Salz, Rich
* No, I don't think so. The server might choose to not support one of the TLS 1.3 ciphers, for instance. And even if that weren't true, how would we add new ciphers? Standard TLS negotiation. I don’t see that we need to specify ciphers at the DNS layer. A client with new ciphers will add it

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Eric Rescorla
On Tue, Nov 20, 2018 at 7:40 PM Salz, Rich wrote: > >- No, I don't think so. The server might choose to not support one of >the TLS 1.3 ciphers, for instance. And even if that weren't true, how would >we add new ciphers? > > > > Standard TLS negotiation. I don’t see that we need to sp

Re: [TLS] ESNIKeys over complex

2018-11-20 Thread Paul Wouters
On Wed, 21 Nov 2018, Stephen Farrell wrote: We currently permit >1 RR, but actually I suspect that it would be better to try to restrict this. Not sure we can and I suspect that'd raise DNS-folks' hackles, but maybe I'm wrong. I think the SOA record is the only exception allowed (and there i