On 4 November 2016 at 09:11, Salz, Rich wrote:
> I think the issue about signature contexts first, and mainly, came up with
> TLS which generates a variety of private key material based on shared secret
> info, and the concern that those different keys could be used for
> cross-protocol attac
This is also my understanding. but I might be wrong as well.
Yours,
Daniel
On Thu, Nov 3, 2016 at 6:11 PM, Salz, Rich wrote:
> I think the issue about signature contexts first, and mainly, came up
> with TLS which generates a variety of private key material based on shared
> secret info, and t
I think the issue about signature contexts first, and mainly, came up with TLS
which generates a variety of private key material based on shared secret info,
and the concern that those different keys could be used for cross-protocol
attacks.
But I could be wrong. :)
--
Senior Architect, Ak
Daniel Migault writes:
> Hi,
>
> This message starts a Working Group Last Call (WGLC) for
> draft-ietf-curdle-dnskey-eddsa-01.
>
> The version to be reviewed is
> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01
Hello again. Since my last review of -01, I have re-read the document
Hi all -
Let's set the meeting time for Tuesday at 1845 - so shortly after the last
session of the day - budget an hour of time.
Space is technically TBD but will be at the meeting hotel. I'll let you
know when I know - but that might not be until IETF week.
-Patrick
On Fri, Oct 21, 2016 at 7
On 03/11/2016 17:57, Wessels, Duane wrote:
> Hi Ray,
>
>
>> QTn: a 2 byte field (MSB first) specifying a DNS RR type. The RR
>> type MUST be for a real resource record, and MUST NOT refer to a
>> pseudo RR type such as "OPT", "IXFR", "TSIG", "*", etc.
> How is an implementation expected to k
At Wed, 02 Nov 2016 15:10:18 +0900 (JST),
fujiw...@jprs.co.jp wrote:
> I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
> improve resolver algorithm.
>
> Please read it and comment.
As promised, here are specific comments on the draft text:
- general: the title and file name see
Hi Ray,
>QTn: a 2 byte field (MSB first) specifying a DNS RR type. The RR
>type MUST be for a real resource record, and MUST NOT refer to a
>pseudo RR type such as "OPT", "IXFR", "TSIG", "*", etc.
How is an implementation expected to know which types are pseudo? Should this
docume
On Wed, Nov 2, 2016 at 6:52 PM, 神明達哉 wrote:
> At Wed, 02 Nov 2016 15:10:18 +0900 (JST),
> fujiw...@jprs.co.jp wrote:
>
> > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
> > improve resolver algorithm.
> >
> > Please read it and comment.
>
> In short: I support the motivation o
On Nov 3, 2016, at 11:12 AM, Bob Harold wrote:
> I think it should be noted that this also creates a privacy issue for some
> special-use domain names.
> (Not just an operational problem for operators.)
>
>
> 4.1.2
> last paragraph:
>
>One point to take from this is that there is already a
On Sun, Oct 30, 2016 at 3:12 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title : The ALT Special Use Top Level Domain
> Authors
On 3 November 2016 at 08:59, Bob Harold wrote:
>
>
> 2.4. The Procedure
> Second paragraph under "Signing Migration",
> "ganinig" -> "gaining"
>
> In "Post Migration"
> "severs" is correct, but it looks so much like a common misspelling of
> "server" that I would replace it with "stops" or "brea
On Sun, Oct 30, 2016 at 11:49 PM, Matthew Pounsett
wrote:
> Hi all.
>
> I've submitted an update for the below draft which I'd like the working
> group to eventually consider for adoption. If there's time in the agenda,
> I'd like to ask the chairs for some time to discuss this in Seoul.
>
> As
Dear all,
I have incorporated the comments from Simon changing
Security Considerations and removing the Section about
Implementations.
I have also clarified usage of context. The context label
is used only for Ed448.
I have also updated the example for Ed25519, but I would
really appreciate if
On Mon, Oct 31, 2016 at 11:42 AM, Paul Wouters wrote:
> On Mon, 31 Oct 2016, internet-dra...@ietf.org wrote:
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations of the
>> IETF.
>>
>>Tit
On Mon, Oct 31, 2016 at 1:39 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title : Special-Use Names Problem Statement
> Authors :
On 03/11/2016 12:21, william manning wrote:
> flogging a dead horse. Did you see this?
> https://www.rfc-editor.org/rfc/rfc6804.txt
I didn't see that before, but DNSOP doesn't seem to be able to decide
whether the horse is really dead yet or not.
Of the potential solutions on the table, mine se
flogging a dead horse. Did you see this?
https://www.rfc-editor.org/rfc/rfc6804.txt
On Wed, Oct 26, 2016 at 2:23 AM, Ray Bellis wrote:
> This is a very minor update, mostly just to keep the document alive.
>
> Ray
>
> Forwarded Message
> Subject: New Version Notification for
On 02/11/2016 22:16, Paul Hoffman wrote:
>>> - It feels like combining both class and type into ClassType might be
>>> over-optimization. Since Class will almost always be IN, why not just
>>> have this as its own object member?
>>
>> I was also looking at this and there are some values which are
Daniel,
On Nov 2, 2016, at 11:55 PM, Daniel Migault
mailto:daniel.miga...@ericsson.com>> wrote:
If you believe that the document is ready to be submitted to the IESG for
consideration as a Standards Track RFC please send a short message stating this.
>From a DNS perspective I support the draft a
It's just a DNS record. It doesn't matter what's inside, so I'll
replace the example with something neutral like MX.
O.
--
Ondřej Surý -- Technical Fellow
CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
ma
21 matches
Mail list logo
