Eric:
I have not had a chance to look at the draft yet, but based on your cover note
you seem to have several requirements in common with RFC 3820.
Russ
On Jul 7, 2016, at 3:28 PM, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delegation
> mechanism. A fe
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : A DANE Record and DNSSEC Authentication Chain
Extension for TLS
Authors : Melinda Shore
Eric Rescorla writes:
>We've talked several times about designing some sort of TLS delegation
>mechanism. A few of us got together and put together some initial thoughts
>about the options at:
>https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
That's going to be a tricky one. The PKIX
On Jul 7, 2016 12:29 PM, "Eric Rescorla" wrote:
>
> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
>
> The gener
On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara
wrote:
>
> I also checked if one could do some funky stuff with credential lifetime
> notation to limit the lifetime. Nothing came up (apart for using 16-bit
> count in decaseconds (das) only allowing presenting lifetimes up to 7
> days, 14 hours, 2
On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara
wrote:
> On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> > We've talked several times about designing some sort of TLS delegation
> > mechanism. A few of us got together and put together some initial
> thoughts
> > about the options
On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
>
> I agree, and I think it is clear that client puzzles can be a useful
> addition to the DDoS defense toolbox. However, most of this can be handled
> at the higher levels above TLS, or possibly as a custom extension that does
> not complicate TLS.
>
A custom extension is a promising approach: thi
With Hugo's analysis of the secure channel-like security afforded even when the
application key is used to encrypt non-application data, and as Cédric pointed
out to me the application key will be used to encrypt non-application data like
certain alert messages; so I think option 1 is a reasonab
We've talked several times about designing some sort of TLS delegation
mechanism. A few of us got together and put together some initial thoughts
about the options at:
https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
The general idea here is to have some mechanism for allowing what
are e
On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote:
> On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote:
>> Hiya,
>>
>> Just on this one thing...
>>
>> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote:
>>>
>>> does not make the situation any worse
>>> than we have today.
>> I don't accept t
On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote:
> Hiya,
>
> Just on this one thing...
>
> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote:
> >
> > does not make the situation any worse
> > than we have today.
> I don't accept that is the correct goal. That form of
> argument is what
I do not have an objection to option 1 if re-phrased as
Option 1 - use the same key for protecting both *post*-handshake and
applications messages..
I believe this is what was intended by that option anyway. Let me clarify.
I understand the question as relating *only* to post-handshake messages a
On 7/07/2016, at 10:37 am, Stephen Farrell wrote:
> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote:
>> does not make the situation any worse
>> than we have today.
>
> I don't accept that is the correct goal. That form of
> argument is what lead to us standardising the HTTP
> Forwarded header
Hiya,
Just on this one thing...
On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote:
> does not make the situation any worse
> than we have today.
I don't accept that is the correct goal. That form of
argument is what lead to us standardising the HTTP
Forwarded header field, which IMO was a disim
On Tue, 2016-07-05 at 15:24 +0100, Stephen Farrell wrote:
> it doesn't contribute nor affect the security in any way).
> > > Does that id need to be static? If so, then it'd act as an
> > > additional way to track a user roaming over different IP and
> > > ports. That'd be a pity. If such an id is
On Thu, Jul 07, 2016 at 07:10:20AM +0200, Karthikeyan Bhargavan wrote:
> If we are left with 1 or 3, the miTLS team would prefer 1.
Yeah, me too.
> On the cryptographic side, Hugo has a recent (draft) paper that seems
> to provide some more justification for (1), at least for client
> authenticat
17 matches
Mail list logo
