Acknowledged. This will be in draft-12.
On Sun, Mar 20, 2016 at 5:27 PM, Joseph Salowey wrote:
> No objection, it looks good. I don't see any objections on the list so I
> say merge it.
>
> On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla wrote:
>
>> It sounds like we have general consensus h
No objection, it looks good. I don't see any objections on the list so I
say merge it.
On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla wrote:
> It sounds like we have general consensus here. Does anyone object to my
> merging
> this PR?
>
> -Ekr
>
>
> On Thu, Mar 17, 2016 at 10:34 AM, Ilari Li
It sounds like we have general consensus here. Does anyone object to my
merging
this PR?
-Ekr
On Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara
wrote:
> On Tue, Mar 15, 2016 at 05:37:20PM +, David Benjamin wrote:
> > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
> >
> >
> > I would
On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla wrote:
> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin
> wrote:
>
>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>>
>>> - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then
>>> we'll probably want to define
>>>
>> code
On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin
wrote:
> On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla wrote:
>
>> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin
>> wrote:
>>
>>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>>>
- If we decide to allow PKCS#1 v1.5 for in-protocol
On Tue, Mar 15, 2016 at 05:37:20PM +, David Benjamin wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>
>
> I would probably characterize it less as suites vs orthogonality, but as
> wanting to keep divisions in meaningful and universal places and not
> splitting up tightly-coup
On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin
wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>
>> David,
>>
>> Thanks for being patient with me here. Sorry it took so long
>>
>> As usual, this seems like a question of whether we're going to want a lot
>> of flexibility
>> (thus
On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
> David,
>
> Thanks for being patient with me here. Sorry it took so long
>
> As usual, this seems like a question of whether we're going to want a lot
> of flexibility
> (thus motivating orthogonal negotiation) versus whether we're going to
>
David,
Thanks for being patient with me here. Sorry it took so long
As usual, this seems like a question of whether we're going to want a lot
of flexibility
(thus motivating orthogonal negotiation) versus whether we're going to want
little flexibility
(thus motivating suites). I think that with t
On Mon, Feb 29, 2016 at 05:16:44PM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote:
> >
> > I'm not sure. I agree that the CFRG thing seems to be a new development.
> > I'll
> > try to confirm my previous opinion or develop a new one over the weekend :)
> >
>
>
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote:
> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin
> wrote:
>
>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett
>> wrote:
>>
>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>>> > This is a proposal for revising SignatureAlgorit
Sorry, I'd meant to add this note to the message below and forgot:
In putting together the PR, I noticed that eddsa is currently in the draft
as always paired with no hash rather than the one it uses internally. So
the problem about advertising {sha512, eddsa} and eddsa_448 doesn't occur.
My bad,
I've put together a pull request with some initial text for this proposal
if folks decide to adopt it.
https://github.com/tlswg/tls13-spec/pull/404
(I'm sure there's no end of editorial problems. I think this is the first
time I've done non-trival spec work.)
David
On Fri, Jan 15, 2016 at 3:45 P
On Tue, Jan 19, 2016 at 10:08:45PM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote:
>
> > David Benjamin wrote:
> >
> >> (Whether such certificates exist on the web is probably answerable via CT
> >> logs, but I haven't checked.)
> >>
> >
> > Me neither, and I t
Sorry, sent from the wrong address.
On Tue, Jan 19, 2016 at 5:19 PM David Benjamin wrote:
> On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck wrote:
>
>> Hi,
>>
>> I generally like the idea of simplifying the different algorithm
>> negotiation things, but:
>>
>> On Fri, 15 Jan 2016 20:45:34 +
>> D
On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote:
> David Benjamin wrote:
>
>> (Whether such certificates exist on the web is probably answerable via CT
>> logs, but I haven't checked.)
>>
>
> Me neither, and I think that's the key thing that would need to be checked
> to see if my suggestion
On Tue, Jan 19, 2016 at 06:55:49PM +, David Benjamin wrote:
> On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote:
>
> >
> > Problem I am pointing out is that NamedGroup specifies not only what
> > curves can be used for signing but also what curves can get signed.
> >
> > Or are you saying th
On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote:
> > > If it does not specify the DH share signed, it doesn't really change
>
> > anything...
> >
> > Why would it need to specify what [DH group's] DH share gets signed?
> > NamedGroup still exists for the key exchange (see step 1). I'm only
> >
On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario
wrote:
> > On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > > Hi folks,
> > >
> > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm.
> > > In
> > > TLS 1.2, signa
On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario wrote:
> On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > Hi folks,
> >
> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
> > TLS 1.2, signature algorithms are spread across the handshake. We
> > have SignatureAlgorit
On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> Hi folks,
>
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
> TLS 1.2, signature algorithms are spread across the handshake. We
> have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and
> HashAlgorithm, all in ind
On Friday 15 January 2016 17:13:29 Brian Smith wrote:
> David Benjamin wrote:
> > (Whether such certificates exist on the web is probably answerable
> > via CT logs, but I haven't checked.)
>
> Me neither, and I think that's the key thing that would need to be
> checked to see if my suggestion is
- Original Message -
> Hi,
> > - rsapss_sha256
> > - rsapss_sha384
> > - rsapss_sha512
> > - ecdsa_p256_sha256
> > - ecdsa_p256_sha384
> > - ecdsa_p256_sha512
> > - ecdsa_p384_sha256
> > - ecdsa_p384_sha384
> > - ecdsa_p384_sha512
> > - ecdsa_p521_sha256
> > - ecdsa_p521_sha384
> > - ecdsa_
On Sat, Jan 16, 2016 at 11:01:12AM +0100, Hanno Böck wrote:
>
> > - rsapss_sha256
> > - rsapss_sha384
> > - rsapss_sha512
> > - ecdsa_p256_sha256
> > - ecdsa_p256_sha384
> > - ecdsa_p256_sha512
> > - ecdsa_p384_sha256
> > - ecdsa_p384_sha384
> > - ecdsa_p384_sha512
> > - ecdsa_p521_sha256
> > - ec
Hi,
I generally like the idea of simplifying the different algorithm
negotiation things, but:
On Fri, 15 Jan 2016 20:45:34 +
David Benjamin wrote:
> [2]
> 0x-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
> this is wire-compatible with TLS 1.2.
> - 0x0101 - rsa_pkcs1_md5
On Sat, Jan 16, 2016 at 01:10:06AM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
>
> Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
> lose them. I just wrote out all 9 without thinking about it much. Apart
> from "please don't cause me
David Benjamin wrote:
> (Whether such certificates exist on the web is probably answerable via CT
> logs, but I haven't checked.)
>
Me neither, and I think that's the key thing that would need to be checked
to see if my suggestion is viable.
3. You get better interoperability with TLS 1.2's NSA
On Fri, Jan 15, 2016 at 8:10 PM David Benjamin
wrote:
> If changing the existing meaning is a nuisance, another option is to
> continue to allocate new values but only define ecdsa_p256_sha256,
> ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
> is) for TLS 1.3 and late
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin
wrote:
> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett
> wrote:
>
>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
>> > 1.2, signature algorithms are sprea
On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett wrote:
> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> > 1.2, signature algorithms are spread across the handshake.
> [...]
> > I propose we fold the negotia
On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
> David Benjamin wrote:
>
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
>> introduc
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm,
David Benjamin wrote:
> 4. Deprecate ecdsa_sha256, etc., in favor of new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
> introduces new premultiplications, it’s only 9 values with the prune
Hi folks,
This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
1.2, signature algorithms are spread across the handshake. We have
SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
independent registries. NamedGroup is sent in one list, also used for
(E
34 matches
Mail list logo
