> Suppose keyUsage is respected. Who will knowingly shoot themselves
> in the foot and restrict their RSA certificate to just DHE or just
> RSA key transport? This looks like an impractical counter-measure.
I guess we have to trade-off between different levels of “shooting oneself in
the foot”.
On 04 Dec 2015, at 07:56, Valery Smyslov wrote:
> Hi Bryan,
>
> I guess Dmitry is talking about the trick when each datagram is encrypted
> with its own key,
> derived from the "master" session key using some unique public parameter of
> the datagram,
> like its sequence_number. This trick ma
Hi Brian,
> -Original Message-
> From: Bryan A Ford [mailto:brynosau...@gmail.com]
> Sent: Donnerstag, 3. Dezember 2015 10:51
> To: GUBALLA, JENS (JENS); Fabrice Gautier
> Cc: tls@ietf.org
> Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3
> after all?
>
> Hi Jens,
>
>
As far as I understand your proposal makes impossible to use this trick,
if we consider packets loss and reordering.
Actually, if I’m understanding correctly how you’re doing this per-datagram
rekeying, I think it still should be compatible with the hash-table-based
approach I propo
I'm with Valery here. IMHO the proposed mechanism makes little sense because
(politics notwithstanding) it offers little gain in return of a significant
(possibly unacceptable) burden to important use cases.
Personally I'm firmly against it.
Sent from my BlackBerry 10 smartphone on the Veriz
On 12/2/15, Watson Ladd wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum
>>
>> I think that it eliminates all static distinguisher in the protocol
>> for all data covered by the encryption. That is a fantastically
>> wonderful benefit.
>
> What's a "static distinguisher"? Padding solves
Bryan Ford wrote :
> 2. The 2-byte length field in each record's header no longer
> indicates the length of the *current* record but instead indicates
> the length of the *next* record. The length of the first record
> might be defined in a new field we add to the handshake/key-exchange
> proto
On Friday 16 October 2015 22:36:10 Kurt Roeckx wrote:
> On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> > On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > > Unfortunately I don't know how to verify this. Can miTLS cover
> > > this
> > > case?
> >
> > you mean, you want an
On Friday 04 December 2015 00:52:08 Hanno Böck wrote:
> On Thu, 3 Dec 2015 18:45:14 -0500
>
> Watson Ladd wrote:
> > On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck wrote:
> > > So as long as you make sure you implement all the proper
> > > countermeasures against that you should be fine. (Granted: T
On Fri, Dec 4, 2015 at 1:17 PM Hubert Kario wrote:
> On Friday 04 December 2015 00:52:08 Hanno Böck wrote:
> > * Fully deprecate RSA key exchange.
> > The compatibility costs of this one are high. They are even higher
> > considering the fact that chrome wants to deprecate dhe and use rsa as
> >
I will start by re-iterating my initial position that I would prefer that
the DTLS and TLS analysis is going to be the same in terms of masking the
header information. So I decided to do some thought experiments about what
happens if the length were to be encrypted and how many different situation
On Friday, December 4, 2015 12:57 PM, Jim Schaad wrote:
> To: tls@ietf.org
> Subject: [TLS] Analysis of encrypting the headers - what is the length
> ...
>
> DTLS - Given that most DTLS situations are going to want to keep the block
> of data sent small, there is no to little incentive to send mu
> On Dec 4, 2015, at 10:11, Hubert Kario wrote:
>
>> On Friday 04 December 2015 00:52:08 Hanno Böck wrote:
>> On Thu, 3 Dec 2015 18:45:14 -0500
>>
>> Watson Ladd wrote:
On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck wrote:
So as long as you make sure you implement all the proper
co
13 matches
Mail list logo
