Hi,
The call has now ended. The authors have updated the document to address
the issues I raised. The writeup has been uploaded and I have requested
publication.
If anyone has late feedback, please provide it. We will address it at
the latest at the end of the IETF last call, most likely ear
Hi Ilari, Hi Ekr,
a few remarks inline:
~snip~
- The handshake retransmit scheme doesn't seem to work that
> well with post-handshake auth, and even less well with
> session tickets.
Why do you think so? Of course, unreliable transports creates
inconvenience; is it tha
On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote:
>
> I was wondering about one design decision regarding the ack.
>
> If we don't use the epoch instead of the KeyUpdate then there is only
> one other message that does not have an ack, namely the NewSessionTicket
> message. (I mi
I don't think we ever call consensus on this topic. It looks like there is
rough consensus to move forward with RSA-PSS as the MUST implement
algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5.
During the discussion it also seemed that it is realistic that we may want
to add additi
I support a MUST for RSA_PSS for certificate verify, and it does seem like a
good idea to be algorithm agile.
Russ
On Jul 6, 2016, at 1:23 PM, Joseph Salowey wrote:
> I don't think we ever call consensus on this topic. It looks like there is
> rough consensus to move forward with RSA-PSS as
We are the unenviable position of calling consensus between three choices
[0]:
- Option 1 - use the same key for both handshake and applications messages.
- Option 2 - restore a public content type and different keys.
- Option 3 - separately encrypting the content type.
At this point the consensu
Anirudh noted [0] that existing implementation practices in TLS stacks may lead
to additional complexity when implementing TLS cached info on the server side.
The main issue is that the server needs to prepare the ServerHello (and list
the CachedInfo extension) saying which payloads will subsequ
Hi Ilari,
a few remarks inline:
On 07/06/2016 04:47 PM, Ilari Liusvaara wrote:
> On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote:
>>
>> I was wondering about one design decision regarding the ack.
>>
>> If we don't use the epoch instead of the KeyUpdate then there is only
>> on
On Wed, Jul 06, 2016 at 09:25:15PM +0200, Hannes Tschofenig wrote:
> >
> > Being part of regular handshake is problematic, since those are assumed
> > to be tickets, and as such one needs the dynamic PSK key. But the dynamic
> > PSK key includes the entiere handshake up to Client Finished. And thi
Hi Joe,
it might be interesting to note that in the context of the DTLS 1.3
discussion with Ilari it appears that the epoch exposes handshake
messages (vs. application data) since you need a way to find out what
key was used to encrypt the message (and msgs may get re-ordered or lost).
So, I clai
I agree with Brian here on this issue. This is clearly impractical for
IoT devices. For many of those devices we are talking about 32 KB (in
total).
On 06/29/2016 09:25 PM, Brian Smith wrote:
> Dmitry Khovratovich wrote:
>> It allows cheap and memoryless verification by the server even though the
Do IoT devices generally talk to public-facing web servers?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 07/06/2016 10:23 AM, Joseph Salowey wrote:
> I don't think we ever call consensus on this topic. It looks like there
> is rough consensus to move forward with RSA-PSS as the MUST implement
> algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5.
> During the discussion it also se
On Wednesday, July 6, 2016, Salz, Rich wrote:
> Do IoT devices generally talk to public-facing web servers?
>
Yes, I'd consider that part of the "Internet" aspect of "Internet of Things"
--
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www
On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig wrote:
> I agree with Brian here on this issue. This is clearly impractical for
> IoT devices. For many of those devices we are talking about 32 KB (in
> total).
I continue to feel like this is a valid objection to the wrong proposition.
I don't
On 07/06/2016 10:11 PM, Salz, Rich wrote:
> Do IoT devices generally talk to public-facing web servers?
There are different deployment scenarios, as outlined in this ISOC
publication:
http://www.internetsociety.org/doc/iot-overview
In one frequent deployment model the IoT device connects to the
Kyle,
the question for me is whether it will be an effective mechanism when
many devices just do not support it (for a number of reasons)? For IoT
devices the reason is simple: they don't have MBs of memory.
Even the regular puzzle technique has the problem that you have to
adjust the puzzle diff
On Wed, Jul 6, 2016 at 4:23 PM, Hannes Tschofenig wrote:
> the question for me is whether it will be an effective mechanism when
> many devices just do not support it (for a number of reasons)? For IoT
> devices the reason is simple: they don't have MBs of memory.
>
> Even the regular puzzle tech
On Wednesday, July 6, 2016, Andrey Jivsov wrote:
> Was it really the consensus that the group didn't want to allow PKCS-1.5
> negotiated for handshake signatures (for certificate verifies)?
>
Based on my read of this thread: yes. The consensus seems to be to
disallow PKCS #1 signatures in TLS 1.
Hi, Joe
> On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote:
>
> We are the unenviable position of calling consensus between three choices [0]:
>
> - Option 1 - use the same key for both handshake and applications messages.
> - Option 2 - restore a public content type and different keys.
> - Opti
On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir wrote:
> Hi, Joe
>
> > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote:
> >
> > We are the unenviable position of calling consensus between three
> choices [0]:
> >
> > - Option 1 - use the same key for both handshake and applications
> messages.
> > - Opt
On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If we were
> to rename "post-handshake handshake messages" to "post-handshake bonus
> messages" with a distinct bonus_message record type, where would there
> still be an
On Wednesday, July 06, 2016 04:23:23 pm Hannes Tschofenig wrote:
> (And note that I am not saying that IoT devices aren't used for DDoS
> attacks.)
For that matter, I feel like IoT is a larger DDoS risk in the long-term than
other arenas. A botnet of bazillions of little widgets with Internet acc
On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett wrote:
> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> > I'm also curious which post-handshake messages are the problem. If we
> were
> > to rename "post-handshake handshake messages" to "post-handshake bonus
> > messages" with a dist
Salz, Rich writes:
>Do IoT devices generally talk to public-facing web servers?
Yes, in large quantities. Public web servers are often the only channel they
have to the outside world (apart from direct access on the LAN segment they're
on, but that's often only for admin stuff).
(This, inciden
On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote:
> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett
> wrote:
>
>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
>> > I'm also curious which post-handshake messages are the problem. If we
>> were
>> > to rename "post-handshake handsha
On Sun, Jun 19, 2016 at 3:51 AM, Aaron Zauner wrote:
> Hi,
>
>> On 06 Jun 2016, at 21:05, Peter Gutmann wrote:
>>
>> TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or
>> less stabilised, incorporating all the feedback I've had for it (there's only
>> one open question sti
If we are left with 1 or 3, the miTLS team would prefer 1.
On the cryptographic side, Hugo has a recent (draft) paper that seems to provide
some more justification for (1), at least for client authentication.
I know this is a bit off-topic, but the miTLS team would also like to get rid
of 0-RTT
28 matches
Mail list logo
